This is the debian *STABLE* branch. In testing I imagine they would do it quickly...well, within a week.
The point is, stable is supposed to be stable, and only changed for very good cause (which this is), and then only after considerable testing...which this hasn't had. An exception is made for security fixes because it's considered *necessary* to patch vulnerabilities. Otherwise, no. Even if you don't see how it could cause a problem, you don't include changes without considerable review and testing. That's what stable means.
OTOH, if you choose to import it from another repository...it's your choice. And simple to do. (I'll grant that I don't understand the "volitile" response. The repositories I'm aware of are stable, testing, unstable, and experimental. Presumably volitile has something to do with the stable branch.)
Given all that...I don't see how the timezone file could cause a problem, and I don't see why it should have set in the volitile repository for weeks. Perhaps nobody would test it before they needed it?
I rarely watched Saturday Night Live (or was it a radio show?).
Whatever, it was reported as being said by a regional vice-president of the company in the straight news. (A newspaper.) If a retraction was requested, I never saw it.
FWIW, I imagine that Saturday Night Live might well have thought that line worthy of repeating.
P.S.: I checked with Google, and the first page of hits is, indeed, all about Saturday Night Live...but that doesn't change how I remember things.
When that language is included, somebody's going to use it. I'll agree that lawyers tend to push the bounds, but here we're talking about the company that once said "We're the phone company. We don't HAVE to care."*
* Admittedly, this was before the prior breakup...but you'll notice that that's been undone, and now they have less regulation.
That's a *part* of why I said "you can't go entirely by this metric". There are lots of other reasons. E.g., if it were customary to bribe one's way out of jail, with the bribe being set to what the accused could pay, the metric would also fail. I'm sure that both cases happen somewhere.
Perhaps in Canada you can say "These things were mostly done in the past". I haven't looked into the matter. In the US we can't even say "We're only doing it to foreigners.".
You can't go entirely by the fraction of the population in prison...but that's a strong indicator. And by THAT indicator the US is the worst country on the planet. (Still...that's only one metric, even though it is an important one.) If a large percentage of the population is in prison, then people are either rather unhappy with the government, or the govenment is using prison as a source of "temporary" slaves. Or, of course, both.
Still, it does put a slightly different frame on the question. If you save money, the US govt gets a rake off. If you spend money, the US govt gets a rake off. And the US Govt is much more directly involved in atrocities than the Chinese govt. (Well, at least in the ones mentioned. I'm sure you can find other examples...but then so could I, on both sides.)
Different group of guys. Just because they all have Slashdot accounts doesn't make them the same.
Personally, if it hurt the RIAA I'd be all in favor of distribution of their copyright works. Unfortunately, I don't think it does, it only exposes you to risk (not much, but some). As such I think it's stupid. (OTOH, you'd need to pay me large sums to listen to most of what they release as music. $100/hour might do it, if it weren't too loud...and I could play computer games at the same time. So my opinion of relative worth vs. risk may not be normal.)
They're also measuring KWh at the generating plant, and ignoring transmission costs. I suspect, however, that most of the electricity from the Las Vegas plant is being used locally. Doing that with a coal plant would mean situating the coal plant near the use site rather than near the coal mine, and would result in, among other things, a vastly increased cost / KWh, because the coal would be much more expensive after being transported.
Still, coal may well currently be cheaper under current laws and regulations. As I understand transmission losses for electricity don't amount to more than 50% of the energy, and it's a LOT cheaper to maintain the distribution system than to transport the coal. (And you might need to maintain that system anyway for other reasons. So perhaps it wouldn't be fair to include the cost of that system into the cost of coal powered electric plants.)
Nothing is free. You need to weigh the costs and calculate the relationships. Coal puts excess carbon into the air...that's a real cost, even if current laws don't assign a monetary figure to it. As such, coal is to be avoided when possible...but not without limit. Ideally there would be a dollar figure attached to coal (and gas, and gasoline, and...) and the proceeds used to repay those damaged by the effects. That's ideally, and probably impossible to manage. One can't even reasonably assign the effects of, say, any one hurricane to an particular emission of CO2. Rising sea levels are a bit less controversial...now, before they've affected anyone powerful enough to demand payment. They won't remain so. (The law of gravity would be thrown into doubt if there were a commercial interest involved." -- H.L. Mencken)
When I think hydroponics, I tend to think hibiscus or papaya. (They'll barely grow around here, and some winters they die. Banana plants survive...but never fruit.)
I'll agree that standards must be open (and "free" [i.e., libre, not gratis], but not all non-free specifications are formats. It's just that they also aren't standards (no matter WHAT some people may name them).
FWIW, it also affects neural tremor. This would make most forms of compensation for blindness difficult. It could make using a mouse quite difficult.
Still, I can imagine that listening to music is something that she might still enjoy. And given that she can't earn a living...
So "stealing" music *might* seem attractive to her.
This is not evidence that she committed copyright infringement, or was involved in a conspiracy to infringe copyrights. Such evidence as has been made public says that she didn't and wasn't. I'll grant that it isn't conclusive.
OTOH, given the RIAA's know record for accuracy (i.e., approximately random chance) I don't think that she's at fault. And I believe that the RIAA knew that she wasn't at fault. I further believe that the RIAA is engaged in malicious persecution of a disabled person. Possibly the tactics that they are using are not provably illegal. Possibly, but I wouldn't go so far as to say probably.
FWIW, this does not decrease my respect for the RIAA...it was already near the bottom. What this means to me is that there's no particular benefit in respecting copyright laws WRT the music labels, since you're just as likely to be a victim if you don't as if you do. In a way it's a pity that they don't publish anything I'd want to hear, as it might give me a smidgeon of pleasure to "violate their rights". Unfortunately, not enough to pay for listening to the result.
Well, if they keep it up long enough they can kill her in a perfectly legal way. Then all they need to do is back off her estate (which will already have been eaten by legal fees).
I consider what they're engaged in as a legalized form of torturing someone to death for profit.
She's tried NeoOffice...and it was better than OOo 1.x. Now she only uses it if she needs Mac system fonts. (Admittedly this is partially because she can't keep them straight, so I hid the one that's less frequently appropriate. It's in the system folder, but no longer on the toolbar. Nothing beats trying to edit the same file with two programs at once....except trying to explain what happened to someone who can't keep them straight.)
It's wierd the way people have different skill sets...but it can certainly be useful. I use her skills all the time to manage social events. She uses mine to manage computer access. Neither one of us can do what the other does.
I don't expect Canadian or even Mexican H1B workers to give you a fair idea of the problem. Those are people who could leave for home is they were substantially abused. But their contracts are probably not fair examples of normal H1B contracts. And H1B workers reportedly are treated as indentured servants, aren't allowed to change employers, have their contracts misrepresented before they leave home. (Possibly not actually. It could be that they just have no concept of how expensive it is to live in an apartment in a US city.)
Note that H1B contracts aren't standard worker contracts. These are people who aren't being given permanent resident status, and can't earn it without returning home and applying from scratch.
Being against H1B workers is rather against being against slavery...only that's a bit of an overstatement. E.g., I'm not aware of rules that state that if an H1B worker gets married, then any kids are bound by his contract. (They better have dual citizenship, though, or they'll be in a hard way when their parents are deported at the end of the contract...and that's dependant on the rules of the country of origin.)
I'm against H1B workers because it's unfair competition in the same way that slavery is unfair competition. But as I said, I doubt that much of this applies to workers who can leave and return home under their own power. If you treated them the same way, they WOULD leave and return home.
Java version or compiled under gcj? I suspect that THAT may make the difference.
I'm using it on Debian Etch, and I have the gcj version installed. It's pretty fast (it's no AbiWord, but it's pretty fast). I note that there's also available a version that runs under the Java interpreter...which I haven't tried, and don't intend to. It probably has more functionality, but it's not worth the tradeoff to have a slower program with more features...if those "more features" aren't one's I have a need for.
It's proof than Java can tackle really massive projects...and it's commentary on what the results will be.
OTOH, I use OOo on Linux, compiled under gcj (i.e., as a wierd dialect of C++) and it's pretty responsive. I also use it on a Mac...and it's not the same experience at ALL. It's so bad that I have trouble getting my wife to use it rather than a graphics program to write her letters in.... Well, that's probably more than just Java, but I notice that the Gimp on the Mac doesn't have the same glacial use... and it's more X Windows dependant then is OpenOffice, so perhaps it *IS* just the difference between native compilation vs. running in an interpreter (pardon me, virtual machine). Interpreters are almost always slow. With a well-done interpreter you count on the added flexibility to make up the difference, but I'm not convinced that Java HAS that flexibility. (Well, I haven't used Java much, so I'll concede that my opinion isn't very valuable, but Python and Ruby are flexible, Java emulates a compiler [which is why gcj is able to consider Java to be a dialect of C++].)
Does OOo.calc still capitalize words whether you want it to or not? I don't have many uses for a spreadsheet, but the one's that I do require that *I* be in charge of how things are capitalized... so I switched to gnumeric, even though I use OOo for most office suite appications.
Since this suite is based around ODT, that means that OOo files will be compatible. Seems good to me.
Yes, it's quite probable that the "Enterprise Version" will have additional capabilites that aren't free. But compatibility will be free. Just not the added features. It doesn't matter to me if you need to pay extra for non-standard features, or for IBM support. Those both sound fair. (I'll probably decide that I don't need their extra features and support...I've done so since they dropped "VisualAge for Java". Proprietary tie-ins are just too unreliably subject to discontinuance.)
But ODT support is worth a lot! If I never use their software, it's still worth a lot to me, because it means I can send document to those who *DO* use their software.
Somebody's writing without thinking. Most of the distro providers "fork the kernel" in a temporary way. I.e., they re-compile from source using custom modifications. Red Hat, among others, is well known for this behavior. You can be certain that if any of the dirtro providers had seen a long-term benefit in extending their fork rather then dropping it, and forking again from the next kernel version, then they would have.
Also various developers already maintain forked kernel trees. Alan Chapman comes to mind, but he's only one of many. If someone wanted to start a kernel fork, the material is ready to hand. Nobody does. It's not because they haven't got the means and opportunity, it's because they don't see any advantage.
Linus may be the "top of the pole" position, but most coders are relatively satisfied with his choices. If any weren't, a fork would occur. They've happened in the past. Generally they were only demonstration forks, or experimental versions, but they were still genuine forks. If anyone had wanted to pick them up and run with them, they could have. I presume that there are currently extant forks that are moderately current. The problem is, if you keep them separate, they won't stay current.
In principle, I'm all in favor of forks. That's why I'm in favor of Linux AND the Hurd AND the BSD Unixes. And while I'll probably be in favor of OpenSolaris. (Favor is withheld while they're chosing their license...if it's not FOSS I don't want it.) Just being in favor of them doesn't mean that I'll use them. Actually, I've pretty much stayed with Linux since I left MSWind around 2000. I still don't really understand it in depth, so I'm not likely to make that kind of investment in multiple OSes, even ones that are pretty similar. Which gets into why specializing an OS for only servers or only desk tops is a bad idea. It fragments your user base in a bad direction. It makes it unlikely that any one developer will know in depth both the development environment and the execution environment (unless the application is intended to only run or desktops, or is to be developed on servers). And as a result it's likely to fragment your applications in an unpleasant way.
N.B.: As the decades go by if two branches of a fork survive they are likely to become increasingly distant. At first any application that would run on one, would also run on the other. This wouldn't be true a year later. A decade later it would be an unreasonable expectation for an application chosen at random. In two decades there might be only a handful that would run in both environments...without special handling. (I'm not including via use of wine-like emulators.)
IIRC, the "large contract" was to sell software to some bank in Russia. Don't know how large the contract was, as I didn't bother to look. Now if we were to consider why a bank in Russia would buy their software from SCOg, then we might begin to speculate that the bank wasn't surprised at this result...and may have received other considerations that make the contract worthwhile as long as they don't have to actually *use* SCOg's software.
(If you doubt my assessment of their software quality [fair, since I've neither used it nor read the documentation]...consider what their customers have been doing.)
There's a problem here. Novell's money is Novell's, SCO is just holding it for them.
As such, SCO can't legally use Novell's money to pay it's own debts. "Unfortunately" SCO has been keeping lousy books, and didn't keep straight which money was Novell's. The legal hearing that they've stalled with this bankruptcy plea was to determine the size of the amount of money owed to Novell.
As such, I think any CPA involved in this scam *SHOULD* be in serious trouble. It's not certain that this will pierce the corporate shield, and allow Novell to go after the management & the board's personal assets...but it's also not clear that it won't.
Another interesting question is criminal charges. Clearly several laws have been broken, and felonies have been committed. It's not clear that any charges will be filed. "The corporation did it" is a common defense, even when all acts of the corporation were, in fact, performed by people. Personally I would rephrase "the corporation did it" by "it was a conspiracy", but this doesn't seem to be legal custom.
Try Pyrex. It speeds up some code a LOT. (For other code it doesn't do much.) And Pyrex is "nearly" compatible with Python.
N.B.: You must compile Pyrex code to run it. Also, Pyrex is most suited to writing "small pieces" for use from Python. But if you were even thinking of Python, and it was the speed that deterred you, look into Pyrex. (Some people use psycho or pypy, but I believe that those are still too beta...and I don't think they generally speed to code as much as Pyrex does.)
Nah, he's already said he likes Ruby, so if Python won't go where he wants he could choose dRuby (distributed Ruby). He wants Python to do it because he's more productive in Python. That's a good reason.
Also, his main goal, changing the language to be more productive on multi-processor systems, is an extermely valid one in a "design for the future" sense. Right now it makes marginal sense, but multi-core & multi-processor systems are becoming more common...and the predictions is the trend will not only continue but intensify.
OTOH, I've seen arguments that a data-flow architecture is inherently better suited for that environment, and I've seen at least one decent language to program in that was data-flow. (Prograf. It showed up for the Apple][ lc, which only had one processor and not threading capability to speak of. It died attempting to transition to MSWind95. It had problems as well as a lot of promise.)
Perhaps Python could add a dataFlow library? The library would need to be coded in C or some such (C is traditional for Python libraries). Perhaps it would need to be an "along side" langauge, like Pyrex. That would tend to have the problem of never having the syntax match that of Python...quite, but there might be compensatory advantages.
At all events, I'm not sure HOW the problem should be solved, merely that it NEEDS to be solved. And this is the reasonable time to address any necessary changes.
P.S.: I also agree that threads, and processes that are handled like threads, are an inappropriate solution. This doesn't mean that I know what the best solution is, merely what it isn't.
N.B.: This is a more than trivial problem, because of all the different levels of parallelism that are out there. Some of them don't HAVE any shared ram. (Think computer clusters.) Some of them have LOTS of shared RAM (think multi-core machines). Some don't share cache ram, but share system ram (multi-processor). And a good solution will need to handle these cases transparently. When you write on one system, you can't be expected to know the environment in which you'll be running. (Perhaps clustered computers could be split out to be handled separately. Those who are running computer clusters are still expected to be knowledgeable at the hardware level.)
It didn't just go away. Politicians were bought by GM. This may not have been true in every city and town, but the evidence from many places is clear and convincing if you look.
Well, it's old news. Done is done. The people who did it are already in their graves. But GM was the prime mover behind the removal of transit in many cities, including the San Francisco Bay Area Key Route and in Los Angelas (I forget what their system was called). And many other places.
OTOH, there's no evidence that they were behind every such event. There is evidence, convincing but, perhaps, not conclusive, that this was a planned corporate strategy. They weren't ashamed of it, though they didn't want it called to the public's attention, as that might interfere with their plans. And it may not have been illegal. (IANAL...but while it's black-hearted treachery to the US, it might have been seen as the corporation's duty to it's stockholders.)
If I recall correctly, federal banks are allowed to lend around half again as much money as they have on deposit, and savings & loans a quarter again. Roughly. It's been a decade or so since I looked this up, so the proportions are almost certainly wrong, but you get the idea.
The interesting thing is that whenever accountants check the books carefully they tend to find that the banks and S&Ls are lending even more than they're allowed to. But the books are VERY rarely checked. (This information also over a decade old.)
So, yes, they are, essentially, printing money. On a small scale compared to the Fed, but, effectively, printing money. But most of the inflation is/was caused by the increased speed of turnover. (This was during the period when bank's accounting was switching over to electronics...so this info is likely to be stale. But think of interest charged on overnight loans. You make the loan at closing time, and demand repayment with interest in the morning. [I *MUST* have that wrong! I still can't imagine why any large number of dollars would flow through such a loan!])
Slashdot Mirror
This is the debian *STABLE* branch. In testing I imagine they would do it quickly...well, within a week.
The point is, stable is supposed to be stable, and only changed for very good cause (which this is), and then only after considerable testing...which this hasn't had. An exception is made for security fixes because it's considered *necessary* to patch vulnerabilities. Otherwise, no. Even if you don't see how it could cause a problem, you don't include changes without considerable review and testing. That's what stable means.
OTOH, if you choose to import it from another repository...it's your choice. And simple to do. (I'll grant that I don't understand the "volitile" response. The repositories I'm aware of are stable, testing, unstable, and experimental. Presumably volitile has something to do with the stable branch.)
Given all that...I don't see how the timezone file could cause a problem, and I don't see why it should have set in the volitile repository for weeks. Perhaps nobody would test it before they needed it?
I rarely watched Saturday Night Live (or was it a radio show?).
Whatever, it was reported as being said by a regional vice-president of the company in the straight news. (A newspaper.) If a retraction was requested, I never saw it.
FWIW, I imagine that Saturday Night Live might well have thought that line worthy of repeating.
P.S.: I checked with Google, and the first page of hits is, indeed, all about Saturday Night Live...but that doesn't change how I remember things.
Not too paranoid.
When that language is included, somebody's going to use it. I'll agree that lawyers tend to push the bounds, but here we're talking about the company that once said "We're the phone company. We don't HAVE to care."*
* Admittedly, this was before the prior breakup...but you'll notice that that's been undone, and now they have less regulation.
That's a *part* of why I said "you can't go entirely by this metric". There are lots of other reasons. E.g., if it were customary to bribe one's way out of jail, with the bribe being set to what the accused could pay, the metric would also fail. I'm sure that both cases happen somewhere.
Perhaps in Canada you can say "These things were mostly done in the past". I haven't looked into the matter. In the US we can't even say "We're only doing it to foreigners.".
You can't go entirely by the fraction of the population in prison...but that's a strong indicator. And by THAT indicator the US is the worst country on the planet. (Still...that's only one metric, even though it is an important one.) If a large percentage of the population is in prison, then people are either rather unhappy with the government, or the govenment is using prison as a source of "temporary" slaves. Or, of course, both.
O, how I wish that weren't accurate.
Still, it does put a slightly different frame on the question. If you save money, the US govt gets a rake off. If you spend money, the US govt gets a rake off. And the US Govt is much more directly involved in atrocities than the Chinese govt. (Well, at least in the ones mentioned. I'm sure you can find other examples...but then so could I, on both sides.)
Different group of guys. Just because they all have Slashdot accounts doesn't make them the same.
Personally, if it hurt the RIAA I'd be all in favor of distribution of their copyright works. Unfortunately, I don't think it does, it only exposes you to risk (not much, but some). As such I think it's stupid. (OTOH, you'd need to pay me large sums to listen to most of what they release as music. $100/hour might do it, if it weren't too loud...and I could play computer games at the same time. So my opinion of relative worth vs. risk may not be normal.)
They're also measuring KWh at the generating plant, and ignoring transmission costs. I suspect, however, that most of the electricity from the Las Vegas plant is being used locally. Doing that with a coal plant would mean situating the coal plant near the use site rather than near the coal mine, and would result in, among other things, a vastly increased cost / KWh, because the coal would be much more expensive after being transported.
Still, coal may well currently be cheaper under current laws and regulations. As I understand transmission losses for electricity don't amount to more than 50% of the energy, and it's a LOT cheaper to maintain the distribution system than to transport the coal. (And you might need to maintain that system anyway for other reasons. So perhaps it wouldn't be fair to include the cost of that system into the cost of coal powered electric plants.)
Nothing is free. You need to weigh the costs and calculate the relationships. Coal puts excess carbon into the air...that's a real cost, even if current laws don't assign a monetary figure to it. As such, coal is to be avoided when possible...but not without limit. Ideally there would be a dollar figure attached to coal (and gas, and gasoline, and...) and the proceeds used to repay those damaged by the effects. That's ideally, and probably impossible to manage. One can't even reasonably assign the effects of, say, any one hurricane to an particular emission of CO2. Rising sea levels are a bit less controversial...now, before they've affected anyone powerful enough to demand payment. They won't remain so. (The law of gravity would be thrown into doubt if there were a commercial interest involved." -- H.L. Mencken)
Wasn't that the point?
When I think hydroponics, I tend to think hibiscus or papaya. (They'll barely grow around here, and some winters they die. Banana plants survive...but never fruit.)
I'll agree that standards must be open (and "free" [i.e., libre, not gratis], but not all non-free specifications are formats. It's just that they also aren't standards (no matter WHAT some people may name them).
FWIW, it also affects neural tremor. This would make most forms of compensation for blindness difficult. It could make using a mouse quite difficult.
Still, I can imagine that listening to music is something that she might still enjoy. And given that she can't earn a living...
So "stealing" music *might* seem attractive to her.
This is not evidence that she committed copyright infringement, or was involved in a conspiracy to infringe copyrights. Such evidence as has been made public says that she didn't and wasn't. I'll grant that it isn't conclusive.
OTOH, given the RIAA's know record for accuracy (i.e., approximately random chance) I don't think that she's at fault. And I believe that the RIAA knew that she wasn't at fault. I further believe that the RIAA is engaged in malicious persecution of a disabled person. Possibly the tactics that they are using are not provably illegal. Possibly, but I wouldn't go so far as to say probably.
FWIW, this does not decrease my respect for the RIAA...it was already near the bottom. What this means to me is that there's no particular benefit in respecting copyright laws WRT the music labels, since you're just as likely to be a victim if you don't as if you do. In a way it's a pity that they don't publish anything I'd want to hear, as it might give me a smidgeon of pleasure to "violate their rights". Unfortunately, not enough to pay for listening to the result.
Well, if they keep it up long enough they can kill her in a perfectly legal way. Then all they need to do is back off her estate (which will already have been eaten by legal fees).
I consider what they're engaged in as a legalized form of torturing someone to death for profit.
She's tried NeoOffice...and it was better than OOo 1.x. Now she only uses it if she needs Mac system fonts. (Admittedly this is partially because she can't keep them straight, so I hid the one that's less frequently appropriate. It's in the system folder, but no longer on the toolbar. Nothing beats trying to edit the same file with two programs at once....except trying to explain what happened to someone who can't keep them straight.)
It's wierd the way people have different skill sets...but it can certainly be useful. I use her skills all the time to manage social events. She uses mine to manage computer access. Neither one of us can do what the other does.
I don't expect Canadian or even Mexican H1B workers to give you a fair idea of the problem. Those are people who could leave for home is they were substantially abused. But their contracts are probably not fair examples of normal H1B contracts. And H1B workers reportedly are treated as indentured servants, aren't allowed to change employers, have their contracts misrepresented before they leave home. (Possibly not actually. It could be that they just have no concept of how expensive it is to live in an apartment in a US city.)
Note that H1B contracts aren't standard worker contracts. These are people who aren't being given permanent resident status, and can't earn it without returning home and applying from scratch.
Being against H1B workers is rather against being against slavery...only that's a bit of an overstatement. E.g., I'm not aware of rules that state that if an H1B worker gets married, then any kids are bound by his contract. (They better have dual citizenship, though, or they'll be in a hard way when their parents are deported at the end of the contract...and that's dependant on the rules of the country of origin.)
I'm against H1B workers because it's unfair competition in the same way that slavery is unfair competition. But as I said, I doubt that much of this applies to workers who can leave and return home under their own power. If you treated them the same way, they WOULD leave and return home.
Java version or compiled under gcj? I suspect that THAT may make the difference.
I'm using it on Debian Etch, and I have the gcj version installed. It's pretty fast (it's no AbiWord, but it's pretty fast). I note that there's also available a version that runs under the Java interpreter...which I haven't tried, and don't intend to. It probably has more functionality, but it's not worth the tradeoff to have a slower program with more features...if those "more features" aren't one's I have a need for.
It's proof than Java can tackle really massive projects...and it's commentary on what the results will be.
... Well, that's probably more than just Java, but I notice that the Gimp on the Mac doesn't have the same glacial use ... and it's more X Windows dependant then is OpenOffice, so perhaps it *IS* just the difference between native compilation vs. running in an interpreter (pardon me, virtual machine). Interpreters are almost always slow. With a well-done interpreter you count on the added flexibility to make up the difference, but I'm not convinced that Java HAS that flexibility. (Well, I haven't used Java much, so I'll concede that my opinion isn't very valuable, but Python and Ruby are flexible, Java emulates a compiler [which is why gcj is able to consider Java to be a dialect of C++].)
OTOH, I use OOo on Linux, compiled under gcj (i.e., as a wierd dialect of C++) and it's pretty responsive. I also use it on a Mac...and it's not the same experience at ALL. It's so bad that I have trouble getting my wife to use it rather than a graphics program to write her letters in.
Does OOo.calc still capitalize words whether you want it to or not? I don't have many uses for a spreadsheet, but the one's that I do require that *I* be in charge of how things are capitalized ... so I switched to gnumeric, even though I use OOo for most office suite appications.
Since this suite is based around ODT, that means that OOo files will be compatible. Seems good to me.
Yes, it's quite probable that the "Enterprise Version" will have additional capabilites that aren't free. But compatibility will be free. Just not the added features. It doesn't matter to me if you need to pay extra for non-standard features, or for IBM support. Those both sound fair. (I'll probably decide that I don't need their extra features and support...I've done so since they dropped "VisualAge for Java". Proprietary tie-ins are just too unreliably subject to discontinuance.)
But ODT support is worth a lot! If I never use their software, it's still worth a lot to me, because it means I can send document to those who *DO* use their software.
Somebody's writing without thinking. Most of the distro providers "fork the kernel" in a temporary way. I.e., they re-compile from source using custom modifications. Red Hat, among others, is well known for this behavior. You can be certain that if any of the dirtro providers had seen a long-term benefit in extending their fork rather then dropping it, and forking again from the next kernel version, then they would have.
Also various developers already maintain forked kernel trees. Alan Chapman comes to mind, but he's only one of many. If someone wanted to start a kernel fork, the material is ready to hand. Nobody does. It's not because they haven't got the means and opportunity, it's because they don't see any advantage.
Linus may be the "top of the pole" position, but most coders are relatively satisfied with his choices. If any weren't, a fork would occur. They've happened in the past. Generally they were only demonstration forks, or experimental versions, but they were still genuine forks. If anyone had wanted to pick them up and run with them, they could have. I presume that there are currently extant forks that are moderately current. The problem is, if you keep them separate, they won't stay current.
In principle, I'm all in favor of forks. That's why I'm in favor of Linux AND the Hurd AND the BSD Unixes. And while I'll probably be in favor of OpenSolaris. (Favor is withheld while they're chosing their license...if it's not FOSS I don't want it.) Just being in favor of them doesn't mean that I'll use them. Actually, I've pretty much stayed with Linux since I left MSWind around 2000. I still don't really understand it in depth, so I'm not likely to make that kind of investment in multiple OSes, even ones that are pretty similar. Which gets into why specializing an OS for only servers or only desk tops is a bad idea. It fragments your user base in a bad direction. It makes it unlikely that any one developer will know in depth both the development environment and the execution environment (unless the application is intended to only run or desktops, or is to be developed on servers). And as a result it's likely to fragment your applications in an unpleasant way.
N.B.: As the decades go by if two branches of a fork survive they are likely to become increasingly distant. At first any application that would run on one, would also run on the other. This wouldn't be true a year later. A decade later it would be an unreasonable expectation for an application chosen at random. In two decades there might be only a handful that would run in both environments...without special handling. (I'm not including via use of wine-like emulators.)
IIRC, the "large contract" was to sell software to some bank in Russia. Don't know how large the contract was, as I didn't bother to look. Now if we were to consider why a bank in Russia would buy their software from SCOg, then we might begin to speculate that the bank wasn't surprised at this result...and may have received other considerations that make the contract worthwhile as long as they don't have to actually *use* SCOg's software.
(If you doubt my assessment of their software quality [fair, since I've neither used it nor read the documentation]...consider what their customers have been doing.)
There's a problem here. Novell's money is Novell's, SCO is just holding it for them.
As such, SCO can't legally use Novell's money to pay it's own debts. "Unfortunately" SCO has been keeping lousy books, and didn't keep straight which money was Novell's. The legal hearing that they've stalled with this bankruptcy plea was to determine the size of the amount of money owed to Novell.
As such, I think any CPA involved in this scam *SHOULD* be in serious trouble. It's not certain that this will pierce the corporate shield, and allow Novell to go after the management & the board's personal assets...but it's also not clear that it won't.
Another interesting question is criminal charges. Clearly several laws have been broken, and felonies have been committed. It's not clear that any charges will be filed. "The corporation did it" is a common defense, even when all acts of the corporation were, in fact, performed by people. Personally I would rephrase "the corporation did it" by "it was a conspiracy", but this doesn't seem to be legal custom.
Caution: IANAL
Try Pyrex. It speeds up some code a LOT. (For other code it doesn't do much.) And Pyrex is "nearly" compatible with Python.
N.B.: You must compile Pyrex code to run it. Also, Pyrex is most suited to writing "small pieces" for use from Python. But if you were even thinking of Python, and it was the speed that deterred you, look into Pyrex. (Some people use psycho or pypy, but I believe that those are still too beta...and I don't think they generally speed to code as much as Pyrex does.)
Nah, he's already said he likes Ruby, so if Python won't go where he wants he could choose dRuby (distributed Ruby). He wants Python to do it because he's more productive in Python. That's a good reason.
Also, his main goal, changing the language to be more productive on multi-processor systems, is an extermely valid one in a "design for the future" sense. Right now it makes marginal sense, but multi-core & multi-processor systems are becoming more common...and the predictions is the trend will not only continue but intensify.
OTOH, I've seen arguments that a data-flow architecture is inherently better suited for that environment, and I've seen at least one decent language to program in that was data-flow. (Prograf. It showed up for the Apple][ lc, which only had one processor and not threading capability to speak of. It died attempting to transition to MSWind95. It had problems as well as a lot of promise.)
Perhaps Python could add a dataFlow library? The library would need to be coded in C or some such (C is traditional for Python libraries). Perhaps it would need to be an "along side" langauge, like Pyrex. That would tend to have the problem of never having the syntax match that of Python...quite, but there might be compensatory advantages.
At all events, I'm not sure HOW the problem should be solved, merely that it NEEDS to be solved. And this is the reasonable time to address any necessary changes.
P.S.: I also agree that threads, and processes that are handled like threads, are an inappropriate solution. This doesn't mean that I know what the best solution is, merely what it isn't.
N.B.: This is a more than trivial problem, because of all the different levels of parallelism that are out there. Some of them don't HAVE any shared ram. (Think computer clusters.) Some of them have LOTS of shared RAM (think multi-core machines). Some don't share cache ram, but share system ram (multi-processor). And a good solution will need to handle these cases transparently. When you write on one system, you can't be expected to know the environment in which you'll be running. (Perhaps clustered computers could be split out to be handled separately. Those who are running computer clusters are still expected to be knowledgeable at the hardware level.)
It didn't just go away. Politicians were bought by GM. This may not have been true in every city and town, but the evidence from many places is clear and convincing if you look.
Well, it's old news. Done is done. The people who did it are already in their graves. But GM was the prime mover behind the removal of transit in many cities, including the San Francisco Bay Area Key Route and in Los Angelas (I forget what their system was called). And many other places.
OTOH, there's no evidence that they were behind every such event. There is evidence, convincing but, perhaps, not conclusive, that this was a planned corporate strategy. They weren't ashamed of it, though they didn't want it called to the public's attention, as that might interfere with their plans. And it may not have been illegal. (IANAL...but while it's black-hearted treachery to the US, it might have been seen as the corporation's duty to it's stockholders.)
If I recall correctly, federal banks are allowed to lend around half again as much money as they have on deposit, and savings & loans a quarter again. Roughly. It's been a decade or so since I looked this up, so the proportions are almost certainly wrong, but you get the idea.
The interesting thing is that whenever accountants check the books carefully they tend to find that the banks and S&Ls are lending even more than they're allowed to. But the books are VERY rarely checked. (This information also over a decade old.)
So, yes, they are, essentially, printing money. On a small scale compared to the Fed, but, effectively, printing money. But most of the inflation is/was caused by the increased speed of turnover. (This was during the period when bank's accounting was switching over to electronics...so this info is likely to be stale. But think of interest charged on overnight loans. You make the loan at closing time, and demand repayment with interest in the morning. [I *MUST* have that wrong! I still can't imagine why any large number of dollars would flow through such a loan!])