[sarcasm] I notice you posted anonymously. Doesn't that seem inconsistent with your views? Or are you currently perpetrating a crime? Or are you only planning one?
Come on, admit it. You're being an Anonymous Coward because you're committing a crime. [/sarcasm]
They needed it because they were trying to speed up execution on smart phones. As I understand it, Dalvik(?) compiles class files produced by the javac compiler to optimize register allocations, and what they are arguing about is the documentation. They aren't trying to use the same name, so it's not related to the MS ploy of defining a non-compatible Java. They're trying to define a (very large) subset of Java+libraries that can be handled by their compiler.
OTOH, it's been months since I paid close attention to this, so I may well have the details considerably garbled. IIUC, however, the question was whether the order in which class methods were listed in the documentation was copyrightable. Originally the answer was no, but it sound like that answer has been changed to yes.
That Oracle dislikes something isn't a condemnation. It's more nearly a recommendation.
That said, I'm dubious about systemd. I almost understand how to use init. OTOH, I prefer the interface of the pre-grub2 grub to the current one. I assume that there must be SOME benefits to the change, but I haven't found any. I expect to end up feeling the same way about systemd.
I saw a blog where someone redrew a chart, and said it was valid data. I don't know the someone, but the blog title, "Real Science", makes me think of a used car salesman..."Honest John". So I didn't take them seriously.
Also, wouldn't you say that to only consider Hurricanes that strike the US is a bit provincial? (That said, when I was a child I *didn't* occur every year, at least not that hit the national news.)
Well, what I mean is that only one copy of any chunk should exist, and it has no externally writeable state. Strings are immutable. long used as indexes are final. State access is only through functions. The chunks should have no shared state. Readable, yes through a getter function, but what is returned is a copy. Either a number or a very small structure (which given Java has to be a class, but in Python would be a tuple).
The problem is that the Goetz book (Java Concurrency in Practice) indicates that this may not be sufficient isolation...and that it may not be enough to synchronize all methods (or blocks within methods) that write to the internal state. OTOH, that's a lot better description of what to do than any of the C++ texts I've acquired have, even if it does leave me feeling uncomfortable. I hope he's just being overcautious, but... and his comments aren't actually language specific, but rather have to do with what optimizers do to code.
To me it looks as if my design SHOULD be thread safe, but I know I'm no expert. Using C++ would apparently require me to become one before being able to do anything. With Java it appears that at most I'll be paying a speed penalty to do things securely, and various comments indicate that if there are no collisions, then synchronization is cheap.
So as to "what kind of synchronization?", the only place I *see* a need for it is on writes...but that's not what the literature (what I know of it) says is needed. Apparently one can end up with a variable that's half written. Well, this can be handled by (in Java) declaring the questionable variables to be volitile. And synchronizing the writes.
I don't WANT to become an expert on parallelism. I don't want to need to become one to write a program that uses it. Currently it looks as if this means that C/C++ are poor choices. Poor compared to Ada. Poor compared to D. And poor compared to Java. (There's a difference between becoming reasonably adept and being an expert. I want my expertise to be focused on a different portion of the program than "How can I get things to work in parallel without everything breaking?". That *is* a vital part, but that's why I'm in the process of choosing a language that makes it reasonably easy, and that handles a lot of the sticky parts in a nearly optimal way. (I hope!)
OTOH, because I don't really like Java, I have been continually looking for something better.
The hash tables are an active copy of portions of the database. How large they'll be is dynamically variable, but I'll probably limit the [String, long] table to 10,000 or so active entries, though the total size will be around 5,000,000, but most of that will be inactive at any one time. The [long, chunk] table will have much more complex values, and many more of them. Basicly as many as I can manage, though again most of them will be rolled out to the database at any one time.
C++ would be a lot more complex than Java because I'd need to build many things that are already available in Java....at least if the Boost libraries are any guide.
As for managed objects...the managed objects would need to be the two main hash tables. And in Java (using threads instead of processes) I can use the already optimized ConcurrentHashMap class. That only locks the entries being accessed rather than the entire table, so there are a lot fewer collisions that would be the case with the Python managed dict.
OTOH, I have heard tales in the past of people running out of room in the Java VM. It was WRT an older version of Java, however, and I'm hoping that it no longer applies.
That said, yes, C++ is a complete language, and you can do anything computable with it. But the same is true of assembler. I'd rather not fight against limitations of the language any more than I must. Python was my first choice for this project, and Ruby was my second, but the more I looked into Python, the less promissing it seemed. At this poiint I'm feeling more like trying Ruby than Python...but Ruby also has it's problems, and its been so long since I've looked at it that I don't really remember what they were.
As for expanding to multiple machines...that's not in the budget for the foreseeable future. When I replace my current machine I'm going to get as many cores as I can afford (as well, of course, as as much RAM, am much disk space, as much speed, etc.), but that's not this month, and likely not this year. And space as well as cost is strictly limited.
If I were after maximum performance I'd switch to Ada. One of the things I'm trying to optimize, however, is developer time...and I haven't used C++ for over 30 years now. The last time I used it the STL hadn't been adopted. I considered it a superior C in the same way that Fortran95 was a superior Fortran, when compared against Fortram IV. (I only used Fortran G a couple of times.)
Damn... now I'm going to need to track down again why I rejected Ruby.
While what you say is true, it's not complete. Most of the "messing with things" has come in the form of increased population. Another large part has come from irrigating deserts beyond the ability of native aquifers to replenish even in the lack of a drought. Also, California has historically had periodic droughts going back over the centuries.
And that STILL doesn't account for all the changes, though in any one particular case you can make an argument that "things like that have always happened". The statistical prevalence has changed. I'm not really sure how much of the dryness of last winter, and late spring rains, can be attributed to global warming. Things like that have always happened occasionally. But now severe ones are happening more frequently. And they may be averaging more severe. That at the same time we are putting more pressure on the state's water reserves doesn't make things any better, but doesn't have any direct bearing on forest fires. That *is* however, affected by poor forestry practices as you mention, but many of those practices are allowing people to build in places where they shouldn't, and feeling we need to protect them anyway. When I was a child there were lots of wild-fires, usually blamed on smokers. They weren't always controlled as quickly as possible. But when people have houses in the forest there seems to be an increased sense of urgency about suppressing the fire as quickly as possible. This is, I believe, the "poor forestry practice" that you were alluding to. OTOH, can you imagine allowing a "controlled burn" to destroy someone's house? It being "good forestry practice" wouldn't prevent the political repercussions.
Because for the last few decades people and their governments have essentially refused to act to ameliorate the damage that they were doing, so all we can do is try to deal with it. We are probably already comitted to a four degree temperature rise, with two degrees the rough estimate of the maximum rise that can happen without serious effects. Probably one of the better ways to deal with this is to grow gills, but so far people aren't willing to even think seriously of what the repercussions are likely to be. Over a century or two I expect most of Antarctica to melt. This means a HUGE rise in ocean levels. Additionally warmer water takes up more room than colder water. (Water is densest at 4 C.) Expect the San Jouquin and Missippi valleys to be permanently flooded with salt water. The Great Salt Lake *may* refill, though I think the ground has risen since it was last alive, so perhaps not. Given the rise in temperatures, these changes may be good, as they will act to ameliorate the local climate.
As usual, timing will be the problem. The changes I was describing will be extremely rapid by geological time scales, but on human time scales they will be only uncomfortably rapid. I expect a couple of centuries, if we can hold the rise to four degrees. (Four degrees is all I feel we're currently comitted to, though some estimates if we continue using coal put the estimate as high as 10 degrees [I don't remember whether that was Centigrade or Fahrenheit].)
P.S.: I am not a climatologist. I merely follow reports in some popular science journals.
You're reacting to this as if it was an unexpected finding. It wasn't...at least in general. Warmer oceans evaporate more, and water is a strong greenhouse gas.
I'm not a climatologist, and certainly not a climatological model builder, so I don't know just how much of the warming was expected to be due to water vapor, but I did know that it was "a lot". Lack of water vapor is why deserts get so cold at night. (It has a lot less to do with why they get so hot during the day, that's more due to lack of liquid water.)
Climate is made up of weather. Any particular instance is weather. A statistical clump of pieces of weather is climate. When they say particular pieces of weather are becoming more common, they are talking about climate.
Idiot. Monopoly doesn't MEAN death threat. It doesn't even mean there's no other provider. It means that there's one provider that controls the market. (It also doesn't mean illegal. Only an abusive monopoly is illegal. Unfortunately, if a monopoly shows up, it will, over time, become abusive. And that can be quite difficult and expensive to prove.)
E.g., I've been using one particular ISP for over a decade, but not because it's good or fast. It's because they own a particular e-mail address. My wife uses that e-mail address for her business. So the ISP has a monoply over her business communications. Yes, there are ways around it, but there aren't any reliable ways to permanently solve the problem, because forwarding of e-mail is not guaranteed. Please note, I doubt that the ISP is even aware that the monopoly over her e-mail address is the reason that we remain a customer. This doesn't keep it from being a monopoly.
Well, the basic architecture is that there is a pair of synchronized hash tables, one being and the other being . Each Chunk instance has it's own private data, and all external methods are synchronized. The main thing it does is send a bunch of different messages to other chunks (indirectly through the hash table). Each thread/process has a bunch of currently active chunks that it continuously loops through. Occasionally one chunk will become inactive, and be rolled out and removed from the hash tables. Also occasionally a chunk that's currently rolled out will be activated (rolled in from the database).
I can see how to do this with threads, if I'm allowed to synchronize methods. It looks difficult to do in C++. (If I'm understanding correctly sharing the concurrent hash tables would be a major problem.) I can see how to do it in Java...partially because of various built in concurrent containers. I can, I think, see how to do it in go, but go appears to be undeveloped in this area. In Python I can see how to do it with threads, but I'd need to build a lot of specialized synchronous things that are already available in Java. I can't see how to do it using multi-process without using managers, and the documentation specifically says that they are notably slow, even compared to normal Python code. It would be easy to do this in D (http://dlang.org/index.html), but D is missing too many libraries. I can "sort of" see how to do this in Ada, but Ada appears to have a diminishing amount of use.
Because of the above I've started this project in Java. I'm not really happy with it, because of other design decisions that they have made (specifically utf-16...also it feels quite verbose), but it appears to be able to do the job, though I won't really know until I try to run it will a full database, and since things haven't bee written yet...
P.S.: I considered shared memory maps, but the documentation that I read said that you needed to know the size that they would have before you used them. That's a really bad fit to my application, which expects to grow and shrink the amount of memory that it requires as it is running. (I may even need to wrap Java's ConcurrentHashMap for this reason, so that I can occasionally free memory by replacing the extant tables with new ones if it doesn't free memory properly...but that's a reasonably simple patch that I can add later.)
After checking some more: With Python3 multiprocessing I'd need to use managers, and the documentation specifically says that managers are slow compared to normal Python code. Python is already around a 3-10 times speed penalty when compared to Java, so that sounds unacceptably poor. FWIW, threading does have penalties associated with a shared RAM space, which is why the synchronization problems. OTOH, if I need to communicate lots of data between separately running tasks, ALL I need is synchronization. With multiprocessing there needs to be separate memory spaces that are kept in sync, and probably separate virtual machines (though that is only hinted at with the comment that the different processes can be running on separate machines).
No language seems to have a multi-thread/process system that is well adapted to the thing I'm trying to write, as I need async execution of things with read access to lots of data, and write access to their own data. In Java I can manage this by making the writable data private to the class, and access from outside only via synchronized getter functions. This is possible in Python3, but seems more difficult. I also looked into Go, but that appears too undeveloped. (See "Concurrency is not Parallelism" and then look up gomaxprocs, especially the warnings associated with its use.) Go looks as if it could be developed into a much better language for multiprocessing than either Java or Python, but it doesn't appear to be there yet.
If the police were doing their purported job, then those pensions would have been well earned. And should have been expensed while the officers were serving (except in the case of medical retirements, which justifiably need funding after the retirement).
That I don't feel they are doing their job doesn't mean that I think that the retirements should be eliminated, it means that I think the officers in question should be fired for cause. It frequently means that I also think they should be prosecuted for various crimes in addition to either misfeasance or malfeasance. (Which various crimes obviously depends on what the officer did.)
Now *that's* very interesting. Certainly it's a point of view I've never heard before (which doesn't mean it's wrong). Any place I could look this up? I've considered Pyro (though not recently), but when I looked it didn't seem a good fit. It appears that it would require a large hose of Python interpreters running at the same time, and that's a poor fit without unlimited RAM. What alternative approaches are there? (I describe the application a bit below.)
I've been having a lot of trouble trying to design the thread management for my application, largely because it uses a different model of parallelism than is common for things like web servers. (It's closer to a graph algorithm.) So for Python I wouldn't be able to use a server / process, which made me think that the GIL *would* be a major problem. I'm trying to build something that's based on a bunch of isolated cell with quite limited channels of communication between them. Each particular "cell" is a collection of class instances that are isolated from all external interaction except for a few channels of communication (implemented through method calls). Synchronizaation is a problem. So is persistance, as each cell, after being active for awhile, will go dormant, and eventually be rolled out to a database, to await being re-invoked. Note that this isn't a highly numeric application, and also not particularly graphical, so neither numpy nor PIL are reasonable candidates for inclusion, and also, for obvious reasons, accessed to the database will be minimized as much as possible.
Perhaps I should look into Go again, but problems with documenting the code (and the documentation of existing code) have previously convinced me that it would be a poor choice.
OTOH, because threads are a limited resource compared to "cells", I can't depend on thread isolation for memory protection. So it's not clear that a threading model is a good choice. I't need to use thread pools, and that means that I'd need to depend on other means of isolation in any event. ("Cells" will need to go in and out of activity fairly quickly.) And documentation is quite important, because the system is going to be much too large to hold in my head. (For Python this means DOxygen, as Sphinx is terrible. Everything ends up out of date as things keep getting redesigned. I'm after developer documentation, not end-user documentation, for which Sphinx is reasonable. Too bad Epydoc doesn't work with Python3. It's much better for Python than is DOxygen.)
FWIW, I've even considered using Ada. It has some constructs that seem ideally designed for my purposes. But it's too difficult to use variable length constructs, documenting code is terrible, and the user community seems to be dying. It also has a difficult form of garbage collection, that appears to be a poor fit to this application.
The panic is caused by CO2 buildup. Avoid that any you avoid the problem.
OTOH, I do usually favor total blood donation. That isn't painless, but should be nearly so. Romans used to favor that form of suicide if they didn't want to face pain.
I don't use MS, but most libraries are designed with it in mind. As I said, glibc does a reasonable job, it's just another "non-standard library dependency" that I would prefer to avoid.
My real preference is utf-8, which both D and Vala handle quite well. So does Python3, but it hides what it's doing from the programmer. utf-32 is an acceptable second choice. It makes some things easier at the cost of using considerably more RAM. Utf-16 (or, as someone said, UCCS-2 [if I've got that right]) is not a reasonable choice. It was a reasonable choice back when int-s were often 16-bits long, because it fit in with the existing CPUs.
For most of what I'm doing anything beyond ASCII-7 is excessive, but I also need to handle the occasional Greek letter, of Sanscrit char. So utf-8 works, and utf-32 works. Wide (64-bit) chars will do the job with simpler code, but it wastes a lot of RAM. Utf-16 doesn't waste quite as much RAM, but it code doesn't get ANY simpler, so it's jusst an lousy compromise. But that's what Java offers. And I'm putting up with it because the C++ way of handling unicode character strings and multi-processing is so much worse. (But I *do* wish that Vala would become usable. It seems to have just stalled at becoming more usable and better documented.)
Well, I'm totally developer, and I *don't* like Ruby. Partially because it's too slow, but mainly because it doesn't support utf-8 (or actually any unicode) well. That needs a gem. I really like Vala even though I find it unusable. (Poor documentation and incomprehensible error messages.) It seems to be aimed only at people who are already experienced in GObject programming...which is a weird target audience for that kind of language.
I *don't* like Java, though that's what I'm using at the moment. I prefer Python and D http://dlang.org/index.html . But Python doesn't handle multi-processing well, and D is missing too many libraries. (Outside of the library problem, D is the best language I've encountered.)
My main gripe with C and C++ is the horrible way that they handle Unicode. And it's not as if they didn't have alternatives available before they even started to deal with it. (C has the argument of "maintaining simplicity" to justify shoving that off to a non-standard library, and glibc does a reasonable job. C++ doesn't have that argument.)
A secondary grip with C/C++ is poor multi-processing. This isn't quite fair, though, because I'd already decided that they were unusable due to the unicode handling issue. (I also don't like Java's choice of utf-16. I much prefer either utf-8 or utf-32. utf-16 seems to inherit the problems of both of the other choices.) Since I'd already decided that they weren't acceptable choices I didn't seriously look into their methods of multi-processing.
Note that for BOTH unicode handling and multi-processing I would prefer D over any other choice I've seen. But the lack of libraries counts as a heavy enough strike against it that I'm using Java..
FWIW, I suspect that both the Dev and the Op sides of you would like D. (Digital Mars D)
This is really stupid, given that hypooxengation is not only a painless way to die, it's reported to be actually pleasant. (This is based on old reports from Air Force pilots with defective oxygen gear. Many survived.)
Just slowly decrease the oxygen levels of the air, and they will not only die, but won't mind a bit.
I envisioned them as being rather like large tapioca pearls filled with water, and that they way you would "drink" them would be to pop a handful into your mouth and chew.
OTOH, "looks rather like a jellyfish" is subject to numerous interpretations. It could be just a floppy thing that come in pint and liter sizes.
The practical problem with solar is that photovoltaics are a poor baseline power supply, because for around half the day it's not available. There *are* solutions, but they're all iffy or expensive. Mirror based solar power is better, but largely untried. (New plants are under construction right now, however.) Unlike photovoltaics, though, mirror based solar power to molten salt to steam to turbine to electricity only makes sense in a centralized plant. Scaling it down to homes increases the cost remarkabley while at the same time reducing the efficiency and increasing the tendency to fail.
I do favor solar power, but batteries are lousy at storing power, so we still need the grid. And we still need to store excess power when it's plentiful and withdraw it when its needed. I think molten salts will provide the needed storage. This implies that the power generated by solar cells would be used as it was generated, and the molten salt backing store would be off-line until evening. That means that the current plans for the molten salt facilities are improper. They don't concentrate enough on storage. It also implies that the grid needs to be updated to allow bidirectional transfer of energy, depending on what is available where and when. Not a small amount of investment there.
But do note that the molten salt generator systems fill in the place that the coal plants currently fill in Germany, but with the ability to start relatively quickly, so they don't need to run all the time. You don't get away from centralized power plants (pity), but you do get a carbon neutral power source that doesn't require a bunch of externalities.
Slashdot Mirror
[sarcasm]
I notice you posted anonymously. Doesn't that seem inconsistent with your views? Or are you currently perpetrating a crime? Or are you only planning one?
Come on, admit it. You're being an Anonymous Coward because you're committing a crime.
[/sarcasm]
They needed it because they were trying to speed up execution on smart phones. As I understand it, Dalvik(?) compiles class files produced by the javac compiler to optimize register allocations, and what they are arguing about is the documentation. They aren't trying to use the same name, so it's not related to the MS ploy of defining a non-compatible Java. They're trying to define a (very large) subset of Java+libraries that can be handled by their compiler.
OTOH, it's been months since I paid close attention to this, so I may well have the details considerably garbled. IIUC, however, the question was whether the order in which class methods were listed in the documentation was copyrightable. Originally the answer was no, but it sound like that answer has been changed to yes.
Yeah. And they *ARE* worse than the previous bunch of bastards.
Remember, the MPAA, RIAA, etc. tend to give more money to Democrats than to Republicans. Republicans prefer other souces for their graft.
That Oracle dislikes something isn't a condemnation. It's more nearly a recommendation.
That said, I'm dubious about systemd. I almost understand how to use init. OTOH, I prefer the interface of the pre-grub2 grub to the current one. I assume that there must be SOME benefits to the change, but I haven't found any. I expect to end up feeling the same way about systemd.
I saw a blog where someone redrew a chart, and said it was valid data. I don't know the someone, but the blog title, "Real Science", makes me think of a used car salesman..."Honest John". So I didn't take them seriously.
Also, wouldn't you say that to only consider Hurricanes that strike the US is a bit provincial? (That said, when I was a child I *didn't* occur every year, at least not that hit the national news.)
Well, what I mean is that only one copy of any chunk should exist, and it has no externally writeable state. Strings are immutable. long used as indexes are final. State access is only through functions. The chunks should have no shared state. Readable, yes through a getter function, but what is returned is a copy. Either a number or a very small structure (which given Java has to be a class, but in Python would be a tuple).
The problem is that the Goetz book (Java Concurrency in Practice) indicates that this may not be sufficient isolation...and that it may not be enough to synchronize all methods (or blocks within methods) that write to the internal state. OTOH, that's a lot better description of what to do than any of the C++ texts I've acquired have, even if it does leave me feeling uncomfortable. I hope he's just being overcautious, but... and his comments aren't actually language specific, but rather have to do with what optimizers do to code.
To me it looks as if my design SHOULD be thread safe, but I know I'm no expert. Using C++ would apparently require me to become one before being able to do anything. With Java it appears that at most I'll be paying a speed penalty to do things securely, and various comments indicate that if there are no collisions, then synchronization is cheap.
So as to "what kind of synchronization?", the only place I *see* a need for it is on writes...but that's not what the literature (what I know of it) says is needed. Apparently one can end up with a variable that's half written. Well, this can be handled by (in Java) declaring the questionable variables to be volitile. And synchronizing the writes.
I don't WANT to become an expert on parallelism. I don't want to need to become one to write a program that uses it. Currently it looks as if this means that C/C++ are poor choices. Poor compared to Ada. Poor compared to D. And poor compared to Java. (There's a difference between becoming reasonably adept and being an expert. I want my expertise to be focused on a different portion of the program than "How can I get things to work in parallel without everything breaking?". That *is* a vital part, but that's why I'm in the process of choosing a language that makes it reasonably easy, and that handles a lot of the sticky parts in a nearly optimal way. (I hope!)
OTOH, because I don't really like Java, I have been continually looking for something better.
Yeah, angle brackets.
The hash tables are an active copy of portions of the database. How large they'll be is dynamically variable, but I'll probably limit the [String, long] table to 10,000 or so active entries, though the total size will be around 5,000,000, but most of that will be inactive at any one time. The [long, chunk] table will have much more complex values, and many more of them. Basicly as many as I can manage, though again most of them will be rolled out to the database at any one time.
C++ would be a lot more complex than Java because I'd need to build many things that are already available in Java....at least if the Boost libraries are any guide.
As for managed objects...the managed objects would need to be the two main hash tables. And in Java (using threads instead of processes) I can use the already optimized ConcurrentHashMap class. That only locks the entries being accessed rather than the entire table, so there are a lot fewer collisions that would be the case with the Python managed dict.
OTOH, I have heard tales in the past of people running out of room in the Java VM. It was WRT an older version of Java, however, and I'm hoping that it no longer applies.
That said, yes, C++ is a complete language, and you can do anything computable with it. But the same is true of assembler. I'd rather not fight against limitations of the language any more than I must. Python was my first choice for this project, and Ruby was my second, but the more I looked into Python, the less promissing it seemed. At this poiint I'm feeling more like trying Ruby than Python...but Ruby also has it's problems, and its been so long since I've looked at it that I don't really remember what they were.
As for expanding to multiple machines...that's not in the budget for the foreseeable future. When I replace my current machine I'm going to get as many cores as I can afford (as well, of course, as as much RAM, am much disk space, as much speed, etc.), but that's not this month, and likely not this year. And space as well as cost is strictly limited.
If I were after maximum performance I'd switch to Ada. One of the things I'm trying to optimize, however, is developer time...and I haven't used C++ for over 30 years now. The last time I used it the STL hadn't been adopted. I considered it a superior C in the same way that Fortran95 was a superior Fortran, when compared against Fortram IV. (I only used Fortran G a couple of times.)
Damn... now I'm going to need to track down again why I rejected Ruby.
While what you say is true, it's not complete. Most of the "messing with things" has come in the form of increased population. Another large part has come from irrigating deserts beyond the ability of native aquifers to replenish even in the lack of a drought. Also, California has historically had periodic droughts going back over the centuries.
And that STILL doesn't account for all the changes, though in any one particular case you can make an argument that "things like that have always happened". The statistical prevalence has changed. I'm not really sure how much of the dryness of last winter, and late spring rains, can be attributed to global warming. Things like that have always happened occasionally. But now severe ones are happening more frequently. And they may be averaging more severe. That at the same time we are putting more pressure on the state's water reserves doesn't make things any better, but doesn't have any direct bearing on forest fires. That *is* however, affected by poor forestry practices as you mention, but many of those practices are allowing people to build in places where they shouldn't, and feeling we need to protect them anyway. When I was a child there were lots of wild-fires, usually blamed on smokers. They weren't always controlled as quickly as possible. But when people have houses in the forest there seems to be an increased sense of urgency about suppressing the fire as quickly as possible. This is, I believe, the "poor forestry practice" that you were alluding to. OTOH, can you imagine allowing a "controlled burn" to destroy someone's house? It being "good forestry practice" wouldn't prevent the political repercussions.
Because for the last few decades people and their governments have essentially refused to act to ameliorate the damage that they were doing, so all we can do is try to deal with it. We are probably already comitted to a four degree temperature rise, with two degrees the rough estimate of the maximum rise that can happen without serious effects. Probably one of the better ways to deal with this is to grow gills, but so far people aren't willing to even think seriously of what the repercussions are likely to be. Over a century or two I expect most of Antarctica to melt. This means a HUGE rise in ocean levels. Additionally warmer water takes up more room than colder water. (Water is densest at 4 C.) Expect the San Jouquin and Missippi valleys to be permanently flooded with salt water. The Great Salt Lake *may* refill, though I think the ground has risen since it was last alive, so perhaps not. Given the rise in temperatures, these changes may be good, as they will act to ameliorate the local climate.
As usual, timing will be the problem. The changes I was describing will be extremely rapid by geological time scales, but on human time scales they will be only uncomfortably rapid. I expect a couple of centuries, if we can hold the rise to four degrees. (Four degrees is all I feel we're currently comitted to, though some estimates if we continue using coal put the estimate as high as 10 degrees [I don't remember whether that was Centigrade or Fahrenheit].)
P.S.: I am not a climatologist. I merely follow reports in some popular science journals.
You're reacting to this as if it was an unexpected finding. It wasn't...at least in general. Warmer oceans evaporate more, and water is a strong greenhouse gas.
I'm not a climatologist, and certainly not a climatological model builder, so I don't know just how much of the warming was expected to be due to water vapor, but I did know that it was "a lot". Lack of water vapor is why deserts get so cold at night. (It has a lot less to do with why they get so hot during the day, that's more due to lack of liquid water.)
Thank you. It's good to see a review from a relatively trustworthy source. Too bad that doesn't include the government.
I wish that weren't a valid point. I happen to think this report is correct, but other reports from the same source do taint its trustworthiness.
It's now 2014, so you're talking about what, one year's worth of data?
Climate is made up of weather. Any particular instance is weather. A statistical clump of pieces of weather is climate. When they say particular pieces of weather are becoming more common, they are talking about climate.
Idiot. Monopoly doesn't MEAN death threat. It doesn't even mean there's no other provider. It means that there's one provider that controls the market. (It also doesn't mean illegal. Only an abusive monopoly is illegal. Unfortunately, if a monopoly shows up, it will, over time, become abusive. And that can be quite difficult and expensive to prove.)
E.g., I've been using one particular ISP for over a decade, but not because it's good or fast. It's because they own a particular e-mail address. My wife uses that e-mail address for her business. So the ISP has a monoply over her business communications. Yes, there are ways around it, but there aren't any reliable ways to permanently solve the problem, because forwarding of e-mail is not guaranteed. Please note, I doubt that the ISP is even aware that the monopoly over her e-mail address is the reason that we remain a customer. This doesn't keep it from being a monopoly.
Well, the basic architecture is that there is a pair of synchronized hash tables, one being and the other being . Each Chunk instance has it's own private data, and all external methods are synchronized. The main thing it does is send a bunch of different messages to other chunks (indirectly through the hash table). Each thread/process has a bunch of currently active chunks that it continuously loops through. Occasionally one chunk will become inactive, and be rolled out and removed from the hash tables. Also occasionally a chunk that's currently rolled out will be activated (rolled in from the database).
I can see how to do this with threads, if I'm allowed to synchronize methods. It looks difficult to do in C++. (If I'm understanding correctly sharing the concurrent hash tables would be a major problem.) I can see how to do it in Java...partially because of various built in concurrent containers. I can, I think, see how to do it in go, but go appears to be undeveloped in this area. In Python I can see how to do it with threads, but I'd need to build a lot of specialized synchronous things that are already available in Java. I can't see how to do it using multi-process without using managers, and the documentation specifically says that they are notably slow, even compared to normal Python code. It would be easy to do this in D (http://dlang.org/index.html), but D is missing too many libraries. I can "sort of" see how to do this in Ada, but Ada appears to have a diminishing amount of use.
Because of the above I've started this project in Java. I'm not really happy with it, because of other design decisions that they have made (specifically utf-16...also it feels quite verbose), but it appears to be able to do the job, though I won't really know until I try to run it will a full database, and since things haven't bee written yet...
P.S.: I considered shared memory maps, but the documentation that I read said that you needed to know the size that they would have before you used them. That's a really bad fit to my application, which expects to grow and shrink the amount of memory that it requires as it is running. (I may even need to wrap Java's ConcurrentHashMap for this reason, so that I can occasionally free memory by replacing the extant tables with new ones if it doesn't free memory properly...but that's a reasonably simple patch that I can add later.)
After checking some more:
With Python3 multiprocessing I'd need to use managers, and the documentation specifically says that managers are slow compared to normal Python code. Python is already around a 3-10 times speed penalty when compared to Java, so that sounds unacceptably poor.
FWIW, threading does have penalties associated with a shared RAM space, which is why the synchronization problems. OTOH, if I need to communicate lots of data between separately running tasks, ALL I need is synchronization. With multiprocessing there needs to be separate memory spaces that are kept in sync, and probably separate virtual machines (though that is only hinted at with the comment that the different processes can be running on separate machines).
No language seems to have a multi-thread/process system that is well adapted to the thing I'm trying to write, as I need async execution of things with read access to lots of data, and write access to their own data. In Java I can manage this by making the writable data private to the class, and access from outside only via synchronized getter functions. This is possible in Python3, but seems more difficult. I also looked into Go, but that appears too undeveloped. (See "Concurrency is not Parallelism" and then look up gomaxprocs, especially the warnings associated with its use.) Go looks as if it could be developed into a much better language for multiprocessing than either Java or Python, but it doesn't appear to be there yet.
If the police were doing their purported job, then those pensions would have been well earned. And should have been expensed while the officers were serving (except in the case of medical retirements, which justifiably need funding after the retirement).
That I don't feel they are doing their job doesn't mean that I think that the retirements should be eliminated, it means that I think the officers in question should be fired for cause. It frequently means that I also think they should be prosecuted for various crimes in addition to either misfeasance or malfeasance. (Which various crimes obviously depends on what the officer did.)
Now *that's* very interesting. Certainly it's a point of view I've never heard before (which doesn't mean it's wrong). Any place I could look this up? I've considered Pyro (though not recently), but when I looked it didn't seem a good fit. It appears that it would require a large hose of Python interpreters running at the same time, and that's a poor fit without unlimited RAM. What alternative approaches are there? (I describe the application a bit below.)
I've been having a lot of trouble trying to design the thread management for my application, largely because it uses a different model of parallelism than is common for things like web servers. (It's closer to a graph algorithm.) So for Python I wouldn't be able to use a server / process, which made me think that the GIL *would* be a major problem. I'm trying to build something that's based on a bunch of isolated cell with quite limited channels of communication between them. Each particular "cell" is a collection of class instances that are isolated from all external interaction except for a few channels of communication (implemented through method calls). Synchronizaation is a problem. So is persistance, as each cell, after being active for awhile, will go dormant, and eventually be rolled out to a database, to await being re-invoked.
Note that this isn't a highly numeric application, and also not particularly graphical, so neither numpy nor PIL are reasonable candidates for inclusion, and also, for obvious reasons, accessed to the database will be minimized as much as possible.
Perhaps I should look into Go again, but problems with documenting the code (and the documentation of existing code) have previously convinced me that it would be a poor choice.
OTOH, because threads are a limited resource compared to "cells", I can't depend on thread isolation for memory protection. So it's not clear that a threading model is a good choice. I't need to use thread pools, and that means that I'd need to depend on other means of isolation in any event. ("Cells" will need to go in and out of activity fairly quickly.) And documentation is quite important, because the system is going to be much too large to hold in my head. (For Python this means DOxygen, as Sphinx is terrible. Everything ends up out of date as things keep getting redesigned. I'm after developer documentation, not end-user documentation, for which Sphinx is reasonable. Too bad Epydoc doesn't work with Python3. It's much better for Python than is DOxygen.)
FWIW, I've even considered using Ada. It has some constructs that seem ideally designed for my purposes. But it's too difficult to use variable length constructs, documenting code is terrible, and the user community seems to be dying. It also has a difficult form of garbage collection, that appears to be a poor fit to this application.
The panic is caused by CO2 buildup. Avoid that any you avoid the problem.
OTOH, I do usually favor total blood donation. That isn't painless, but should be nearly so. Romans used to favor that form of suicide if they didn't want to face pain.
I don't use MS, but most libraries are designed with it in mind. As I said, glibc does a reasonable job, it's just another "non-standard library dependency" that I would prefer to avoid.
My real preference is utf-8, which both D and Vala handle quite well. So does Python3, but it hides what it's doing from the programmer. utf-32 is an acceptable second choice. It makes some things easier at the cost of using considerably more RAM. Utf-16 (or, as someone said, UCCS-2 [if I've got that right]) is not a reasonable choice. It was a reasonable choice back when int-s were often 16-bits long, because it fit in with the existing CPUs.
For most of what I'm doing anything beyond ASCII-7 is excessive, but I also need to handle the occasional Greek letter, of Sanscrit char. So utf-8 works, and utf-32 works. Wide (64-bit) chars will do the job with simpler code, but it wastes a lot of RAM. Utf-16 doesn't waste quite as much RAM, but it code doesn't get ANY simpler, so it's jusst an lousy compromise. But that's what Java offers. And I'm putting up with it because the C++ way of handling unicode character strings and multi-processing is so much worse. (But I *do* wish that Vala would become usable. It seems to have just stalled at becoming more usable and better documented.)
Well, I'm totally developer, and I *don't* like Ruby. Partially because it's too slow, but mainly because it doesn't support utf-8 (or actually any unicode) well. That needs a gem. I really like Vala even though I find it unusable. (Poor documentation and incomprehensible error messages.) It seems to be aimed only at people who are already experienced in GObject programming...which is a weird target audience for that kind of language.
I *don't* like Java, though that's what I'm using at the moment. I prefer Python and D http://dlang.org/index.html . But Python doesn't handle multi-processing well, and D is missing too many libraries. (Outside of the library problem, D is the best language I've encountered.)
My main gripe with C and C++ is the horrible way that they handle Unicode. And it's not as if they didn't have alternatives available before they even started to deal with it. (C has the argument of "maintaining simplicity" to justify shoving that off to a non-standard library, and glibc does a reasonable job. C++ doesn't have that argument.)
A secondary grip with C/C++ is poor multi-processing. This isn't quite fair, though, because I'd already decided that they were unusable due to the unicode handling issue. (I also don't like Java's choice of utf-16. I much prefer either utf-8 or utf-32. utf-16 seems to inherit the problems of both of the other choices.) Since I'd already decided that they weren't acceptable choices I didn't seriously look into their methods of multi-processing.
Note that for BOTH unicode handling and multi-processing I would prefer D over any other choice I've seen. But the lack of libraries counts as a heavy enough strike against it that I'm using Java..
FWIW, I suspect that both the Dev and the Op sides of you would like D. (Digital Mars D)
This is really stupid, given that hypooxengation is not only a painless way to die, it's reported to be actually pleasant. (This is based on old reports from Air Force pilots with defective oxygen gear. Many survived.)
Just slowly decrease the oxygen levels of the air, and they will not only die, but won't mind a bit.
I envisioned them as being rather like large tapioca pearls filled with water, and that they way you would "drink" them would be to pop a handful into your mouth and chew.
OTOH, "looks rather like a jellyfish" is subject to numerous interpretations. It could be just a floppy thing that come in pint and liter sizes.
The practical problem with solar is that photovoltaics are a poor baseline power supply, because for around half the day it's not available. There *are* solutions, but they're all iffy or expensive. Mirror based solar power is better, but largely untried. (New plants are under construction right now, however.) Unlike photovoltaics, though, mirror based solar power to molten salt to steam to turbine to electricity only makes sense in a centralized plant. Scaling it down to homes increases the cost remarkabley while at the same time reducing the efficiency and increasing the tendency to fail.
I do favor solar power, but batteries are lousy at storing power, so we still need the grid. And we still need to store excess power when it's plentiful and withdraw it when its needed. I think molten salts will provide the needed storage. This implies that the power generated by solar cells would be used as it was generated, and the molten salt backing store would be off-line until evening. That means that the current plans for the molten salt facilities are improper. They don't concentrate enough on storage. It also implies that the grid needs to be updated to allow bidirectional transfer of energy, depending on what is available where and when. Not a small amount of investment there.
But do note that the molten salt generator systems fill in the place that the coal plants currently fill in Germany, but with the ability to start relatively quickly, so they don't need to run all the time. You don't get away from centralized power plants (pity), but you do get a carbon neutral power source that doesn't require a bunch of externalities.