I didn't say it had to stop. Granted pg_dump slows a system down, but the whole point was to allow hot backups.
That said, I get what you are saying, but in that case, how do you upgrade *anything* (and why)? What happens when a drive fails in your RAID? Do you wave your hands and wail because the speed has dropped during the array rebuild? How do you add drive space, memory, CPU power?
Really what you seem to be lacking, as other posters have mentioned, is redundancy in your database. Granted you will be back to a couple of days for the complete transition, but you are asserting a requirement that 90% of us do not need. Nevertheless, the synchronization option is relatively pain free and allows for the 24/7 uptime you require.
For the rest of us, it'll just be a few (ungodly at 3am) hours at most.
How complete is the API? The power of the Java and.NET VMs (I don't know Parrot well enough to comment) is their standard libraries -- perhaps to a larger extent than the bytecodes themselves.
Array bounds checking is not new. Dynamically loading code isn't new. What was new was the creation of a standardized toolkit and API that handled threading and network I/O and GUI and database access and XML parsing and... You get the picture.
Another portable VM holds little value for me if in the end I just end up back to the "good ol' days" of C where you were given a hammer and told to build a house. POSIX isn't enough.
Static electrical discharge is not necessarily just because one item has an excess (or lack) of electrons. It is because the two points in contact have a substantially different charge. Both items could have an excess of electrons, but if one item has substantially more, there is still a discharge.
That said, it was the "paint." The Hinderburg was draped in cloth. Cloth is inadequate in itself to contain hydrogen, so one must dope it (or paint it, but that implies a different purpose). That "paint" was essentially rocket fuel. In addition to being highly flammable/explosive, it also seals cloth so that it can contain hydrogen.
The Hindenburg caught fire because the cloth it was covered in was doped in what amounts to rocket fuel. The disaster had little to nothing to do with the hydrogen. A charge differential between the tower and the Hindenburg created a spark and ignited the outside covering.
If it had helium instead of hydrogen, it still would have gone up in flames.
You mean that same ISAM format that doesn't support transactions, foreign keys, etc.? That ISAM table format?
In other news, if you can't make a dump of your database, how are you doing backups? You are backing up your database, right? Right? If it's a space issue, how about spending $130 for 200GB on a separate box for temporary storage? And days? C'mon! What are you using? A 233Mhz Pentium with a single IDE drive also doubling as a fileserver?
If you are competent enough to set up a database, you're competent enough to use escaping/unescaping functions.
That said, to make it transparent, just set a trigger and a view. Create a trigger on insert or update to the table in question to run the escape prior to saving to the table. After you've done this once, insert and update as normal from now on. Create a view that selects on the unescaped value. After you've done this once, select from the view as normal from now on.
It's nice that PostgreSQL allows folks to work around these "issues." I don't blame you for not seeing the possibility that people wouldn't want or care about escaped binary data in their database. With MySQL, failure to see possibilities is commonplace. Like for example the fact that triggers and views are probably unknown to you because MySQL doesn't have them. But even though they easily and elegantly address your "problem," I guess they're just "nice extensions."
And for the record, "data" is a piece of information. "Database" is the collection of information -- the collection of data. Storing data is an important task for "database management systems." All the search and calculation features are the raison d'etre.
No more than Perl and Tcl are prerequisites. As with all programming language support in PostgreSQL, you compile what you want in and exclude what you don't want.
Apparently you've never been so poor as to live hand-to-mouth or worry about where rent money is coming from. During those times, if it weren't for the fact that I couldn't afford health insurance, given the choice I would have rather been injured (as long as it wasn't a permanent maiming and rent was covered) than be broke.
As we know, in the real world being injured and broke are far more commonly bedfellows, but that wasn't the hypothetical choice presented.
Money doesn't matter as much to those who have it. To those without it, it's one of the only things that always matters.
I never said that I thought 105-132 columns was unreasonable. I simply said that a 80 column hard limit didn't seem reasonable. You extrapolated that since I was against a 80 column limit, I was against any type of limit. This is not the case.
In addition, until there is such a study, whatever seems to work for a development group is what they should use. If 105 characters works for them, they should use it. I never stated to the contrary.
In the end, I think we agree. Personally, I aim for 80 characters, but if the statement cannot easily be broken up and can be understood easier on a longer line, so be it. In other words, as I said in my previous post, I'm okay with guidelines for line length, but I'm against hard limits.
By the way, what compilers do you use that have line length limitations? Seems pretty lame to me. '\n' is just another character. Then again, so is '\t'. So technically, five indents only raise the number of characters by five. But now I'm just fucking with you.;-)
HTML does not guarantee how your page looks on different browsers.
Pixel for pixel, no it doesn't. Width of blocks via <table width="*"> or CSS's "width" property? HTML most certainly does guarantee this. On text browsers, the console width is the limit. On every browser newer than Netscape 4 -- >95% of the browsers out there -- the CSS property "width" is supported with sufficient correctness to constrain text. The table element covers 99.999%. HTML doesn't need to guarantee how the whole page looks and renders. For the purposes of this conversation, it only needs to guarantee that the texual line width does not exceed a certain value. In this respect, it absolutely guarantees.
HTML is not supposed to? Fine. I can accept that. CSS is supposed to though. Which brings me back to my original -- and I think completely justified -- point: a page that advocates an 80 column limit should not have its own text width unbounded.
My point is the nuclear power industry has been pushing the same "clean" line since its inception, environment groups have nothing whatsoever to do with it. Nuclear power was first presented as the peaceful side of the bomb, so its enonomic disadvantages were forgiven. Fifty years have passed, and it's still an expensive way to boil water with extreme care. The new plants are all in Indonesia, Pakistan, North Korea etc where it is still heavily linked with weapons research.
Point taken. Then again, Indonesia, Pakistan, and North Korea are all examples of countries with unhealthy aspirations for power and/or blood enemies (Pakistan/India, North Korea/South Korea, North Korea/EVERYONE).
But now it is virtually mainstream, twenty years ago it was consigned to the fringes if ever thought of at all, and had no impact whatsoever on energy policy. Blaming them for the economic decisions against nuclear power back then is a cop out.
Granted. You win on this one.
The sol-gel process effectively requires a bucket and a domestic oven, you'll see a lot of industrial ceramics manufactured that way in years to come.
Got any links? What are the energy yields?
Another thing that most people do not realise is that large scale solar power generation is not about a whole lot of silicon cells in a paddock, it's about doing things with heat.
Which is fine, but you're still talking about surface area and the Solar Constant. Whether that 1.367kW/m^2 is in electricity or manifests itself in thermal heat, it is still a very diffuse energy source. But I think I get your point. Passive solar heating in the home (for example) can reduce energy usage dramatically.
They are made of silicon, copper and sometimes aluminium - how can anyone sanely compare this to nuclear waste?
Pound for pound, I'm not. What I was suggesting was that a Connecticut and Delaware of used solar panels is a lot more material to deal with than the equivalent amount of nuclear waste in the same time if breeder-burner nuclear reactors were used. Then again, if existing spent fuel were diffused over as much material as the hypothetical solar panels, the ambient radiation wouldn't be substantially higher than background. There's still the issue of small transuranic particles if they were to enter the lungs, but radon in homes is a more pressing general health concern in my opinion. I don't believe "all chemicals are bad." I also don't believe that "nuclear is warm, fuzzy, and cuddly." When I said, "clean," what I meant was "lower ecological threat when compared to oil, coal, and natural gas as measured in volume and toxicity of pollutants released into the environment." I should have been more specific. I will try to avoid the overused term "clean" from now on.
As for the advertisements and sound bites, I haven't seen many. I grew up and live in a very anti-nuclear part of the country. In fact, most of the people I speak (argue) with fail to distinguish between nuclear power and nuclear bombs. In fact, I used to be vehemently anti-nuclear myself. Then I met someone who graduated with a degree in environmental engineering -- who was also anti-nuclear -- but needed a job and went to work at the Diablo Canyon nuclear facility. He took the job with the agenda of blowing the lid off any coverups and gross mismanagement. Instead he became a nuclear advocate. Years after he left that job and went to work in the software industry, I met him. He was kind enough to go over the halflife radioactivity curves with me. He pointed out to me various sites for information that were not tied to PR arms of the nuclear industry.
Later I came to live with someone who used to work at various power plants around the world, both nuclear and non-nuclear. It was through sources away from the headlines that I came to be a nuclear advoc
The idea is to get that break-even point down to somewhere worthwhile. For instance if breakeven occured after 10-12 years then I would consider it.
Do they require clean rooms for manufacture? If not, you're right. Prices will drop quickly and precipitously with demand. If they do, not so much.
The current generation of PVs basically all require clean rooms to make. While there are some that don't, by and large they either don't have a reasonable lifespan (measured in months) or power output or both.
But you're right. If we hit that break-even point within the lifespan of the components, it will probably be worth it. I just have a hard time seeing 3.8W as anything useful unless it cost less than double-paned glass -- what I see as its greatest market competitor.
I have to admit, you have me wanting to take a closer look at white LEDs for the home. Got any links besides the overpriced VOS Pad? Thanks.
This is true. But the REASON it is easier to read prose is that your eyes don't have to "carriage return" so far after each line. So a line of code really shouldn't be more than 70-80 characters wide for the same reason.
This is true, but once again, code is not prose. You do not read code like you read prose. No one does. This is not to say that you or I or someone else cannot read code very quickly. But it is not prose. Take Japanese prose versus English prose. What formatting is appropriate? How many characters per line? What stylistic attributes are acceptable for indentation, quoting, bibliographic citations, etc.? You can't make one-to-one correlations. Why? They are different animals. They may share some attributes in common, but in the end, they are not the same.
Now, back to code. If your shop standardizes on 105 characters for line length, more power to them. I never said it was a bad thing to standardize a shop's code. What I called into question was a universal belief that 80 characters is somehow a holy construct. Once again, show me the study that compares readability of code and not prose, and I will listen with both ears. Until that happens, you are making the ASSUMPTION that since prose is this way, code must be as well. I do not believe this assumption to automatically be true. It may be, but in my experience, an arbritrary 80 character limit can harm readability rather than help it. Now if you had advocated a 80 character guideline -- rather than a hard limit -- I would be more receptive. Then again, if you advocated a "one statement/one line" approach, I wouldn't be against it either.
It is not up to HTML to tell you how to display the information per say. With a comfortably sized browser window everything should wrap.
Funny, I thought the whole point to HTML (and CSS) was to format information for display. Some web sites have one sidebar. Others have two. Some have none. If sites are not consistent with width, how can a browser be "comfortably sized." This is an abdication of responsibility. If you're responsible for development of a web site, you are also responsible for making that information as easily absorbed as possible. Often times, it may be at 80 columns (or x pixels or y centimeters), but not always.
But then, it is this situation that the CSS property "width" was created for. Or <table width="x"> if you still misguidedly code pages that way.
I've said that because of the wide variety of formatting tools available to produce a "standard form", it should not be necessary for an individual to conform to an arbitrary standard.
So we have a few possibilities. (a) We can put source through the formatter before we start editing and after we finish. (b) We can put an auto-formatter on the source repository. (c) We can get a team meeting and majority rules.
The first is labor intensive and prone to forgetfulness when someone just wants to put a few patches in. The second is a royally bad idea as what you are checking in is not what you were working on. Most of the time it won't be an issue most likely, but it breaks a fundamental source control rule: test before you commit. To put rigor back in, you have to make the code changes, test it, put it through the formatter, test again, and then commit. You don't want to format at the first step because you're still working on it in your own formatting choice. The only other choice is to test redundantly.
More pointedly, how much should I repect a manager and coworkers who can not adapt to my style if I can adapt to theirs?. How do they adapt to foreign code which uses a different style? Reasonable stylistic differences should not matter.
No one said that you had to change. If most of the people on your team prefer your method, then stick with it. I think of source in this case like insurance forms (or some other form).
You can have no end of formatting choices for those forms. All of the forms can have basically the same information. However, when looking through all of these forms for certain bits of info, if all of the forms are different or if you have four or five different formats, finding that information becomes harder for the human eye/brain. If all of the forms are of the same format, if the information being looked for is in the same location each time, searching is faster, easier, and more reliable.
This is of course a loose analogy, but let me put this into more concrete terms: the Java source standard.
lowerFollowedByMixedCase = property lowerFollowedByMixed() = method/function UpperFollowedByMixed = class foo.doSomething() = instance method Foo.doSomething() = method at class scope Foo.ALL_CAPS = a class constant
In other words, without knowing anything at all about the code, I can look at any Java code following this standard and know where to look next. I know whether something is an instance variable or a class declaration. This is something that is sorely missed on the C, C++, et al. end of things. No, I'm not saying that mixed case variable naming is the best. I like it, but not everyone does. That's not my point. My point is that with consistency comes the enhanced ability to spot check code that others wrote (and that I wrote six months ago). It allows for faster and easier understanding of code.
Braces are a minor addendum to this point. Yes, they are relatively unimportant. But they are also easy to adapt to. When in doubt, err on the side of ease of reading.
Braces can be formatted easily. Many other things that are useful for code comprehension cannot. I'm not talking about more strawmen like "banning protected members because they don't fit the code guidelines." I never said a thing about reducing the toolset available to coders. Your job as a coder is to get it working. Bracing style has NOTHING to do with getting it working whether the brace is on the same line or not. It has to do with consistency and readability. And just as with comments, these things should not be tacked on at the end as an afterthought.
Switching brace style is basically instantaneous for me. For most others, it may take part of a day. For the really slow ones, it may take a second day. In any case, it takes less time to learn to do this than it takes to use a formatter over and over again. Yes, the formatter only takes a second or two, but you're advocating it's use for every piece of code you work on.
Anyone who still thinks that Debian is hard to install...
...has used at least one other distribution's installer. Much better than it used to be (what was the name of the kernel module for the chipset in my network card?), but still harder than most others.
Yes, I know the reason: unified installer for all supported platforms. That simply tries to justify the difficulty. It doesn't make the difficulty go away.
That said, I'm a loyal Debian user. I hate putting it on a box, but once it's on, I have no real complaints.
Unless there is a case where someone has an overabundance of money, choices and compromises must be made. It's like when you have to pay $800 in rent, but you only have $500 in the bank account. It doesn't matter how nice that apartment is or how close it is to work.
So for $45 * 95 square feet, you can run the VOS Pad LEDs. Of course, I acknowledge that you pointed out that this is when all lights are on full. What you failed to mention was that the VOS Pad costs £35,000 (about US$52,500). This is not practical. The return on investment would likely take the better part of your life -- if even that short. Sure, it could take this portion of your energy consumption off the grid, but how much energy was required to make these materials in the first place? How much energy was used by the manufacturing facilities? At a price of £35,000, you can bet it isn't peanuts.
As for OLEDs, yes they look promising. However, until they actually hit mass market, we don't know actual numbers. Looking at this press release, Samsung's 17" display "will consume no more power than a 15-inch display..." Sure you can take away the backlight, but this is not the same as slashing the total power consumption. Reduces it, yes, but doesn't make revolutionary drops. On the bright side (no pun intended), OLEDs have the potential for cost savings.
The best thing is to attack it from both ends, the suppy and the demand. I don't understand some of the "it won't supply 100% of my needs" negativity by some people (not yourself). If someone came and showed me how I could lower my electricity bills by eg 50% then I'd be interested.
You're right. We should attack it from both ends or at least leave everything open as possibilities. However I still believe that I was right. We should not concentrate on technologies that only provide marginal improvements for the amount of money/resources spent. We shouldn't ignore them of course, but we definitely shouldn't fixate upon them. We have a limited amount of resources and money. For better or for worse, this is the reality of our world: scarcity and commerce.
Who cares if my electricity bill is reduced by half or even eliminated entirely if the initial cost in materials exceeds what I would pay in electricity for the next fifty years?
If a solution presents itself that uses more resources or costs substantially more than our current methods, it is not a good solution. In some circumstances I could see this PV glass making sense. In most scenarios though, I see it as a curious novelty that makes little sense for the average Joe like myself.
As I look out one of the windows in my bedroom, I estimate that the 2.5 by 3 foot window would cost me around $337.50 to replace just the glass. (I'm sure the framing would add to the cost.) I have three such windows in my bedroom. For some odd reason, I think my money would be better spent on double-paned replacements and using the money saved on both initial investment and heating costs to pay for my energy bills until the technology improves in a few years.
At $45/sq. ft., the $1,012.50 (at least) I would spend on three PV glass windows would not be recouped anytime soon. I like to think of myself as an optimist, but I'm not that blindly optimistic. Assuming 22.5 sq. ft. of PV glass, 3.8W/sq. ft., 7hrs of useable sunlight a day for 22 sunlit days a month (on average), I get a little more than 13kWh (kilowatt hours) per month. Let's say I pay about 10 cents per kilowatt hour -- pretty expensive I think. This means I get back $1.32 every month from these windows. Woohoo! I will have paid for them in 64 years! Well... That's assuming they last for 64 years.
At first, I read it as 3.8kW and said, "Hunh? That's more than the Solar Constant, 1.367kW per square meter." Then I reread it and saw that it was simply 3.8W. This sounded much more reasonable... and small.
This means that a 60W light bulb would need almost 16 square feet to function. Well, that of course is a reason to move to compact flourescents or LED light bulbs. But my computer takes up a bit of power. So does a refridgerator. So does a washer/dryer.
Let's say that it is a television. What's the equivalent of a square foot display (asuming a 5:4 ratio)? About 13"? Can a 13" LCD display work with 3.8W of power? (I don't know. That's why I'm asking.)
I'm not questioning whether it can give power. I'm questioning whether it can give sufficient power to offset the price. Or would the money be better spent elsewhere in green technologies to reduce the actual draw from the grid?
So tell me. How much should I respect you if I am your boss? You've just told me that despite the myriad choices and possibilities available in programming that you cannot adapt to a simple change in bracing style.
If it takes you more than a week to get accustomed to a new formatting style, you will forgive me if I doubt your ability to adapt to a new compiler or new editor or new operating system or development library.
And please stop with the strawman of forbidding polymorphism. Yes, there are moronic shops that forbid certain practices that can be instrumental in solving certain problems. But the parent clearly wasn't talking about those instances. This wasn't a discussion of functionality, it was about aesthetics. Deciding about the amount of whitespace, the capitalization patterns, the bracing style, and the line length do not fall under your diatribe.
And frankly, if you cannot adapt from
if (1) {
}
to
if (1)
{
}
to
if ( 1 )
{
}
or from
write_file()
to
writeFile ()
to
Write_File( )
your problems extend far deeper than your code style.
The question boils down to, "Which formatting style is best?" The answer is simple: "Whatever everyone else on your team is doing." If you cannot adapt to something as simple as this, you cannot be effective in a team. If you cannot be on a team, you are fundamentally useless to 99% of all projects out there. There are better ways to express yourself in code than through bracing style. If formatting style is the best way you can assert your skills and individuality, what does that say about your skills as a programmer overall?
16? With all of the choices available to code with -- languages, libraries, operating systems, compilers, etc. -- your main gripe is bracing style? Are you fucking kidding?
Let me put it this way. Let's say that I'm a prospective employer. I'm looking for someone with a good head on their shoulders, that works well with a team, and can adapt to new situations. Then I hear you say the above statement. So far, what I know of you is that bracing style is a religious doctrine for you, you will not respect any preferences but your own, you will waste time bitching about a coding style instead of getting work done (the "spit fire" comment), and you expect that a codebase could or should have more than one coding style in it -- that or "my way or the highway."
Most employers want someone who works well in a team. "Team" usually implies working together toward a common goal. It requires some uniformity in process. But you aren't even willing to be swayed by something as trivial as bracing style. You probably have an enormous opinion of yourself and yet cannot adapt to a perfectly valid and trivially different coding style.
Nice.
The sad part is, you're useless to both commercial and Free Software camps. Commercial software won't like you for the above reasons. Free Software projects all have different idioms and coding guidelines. Imagine their chagrin when some hotshot comes in and starts spitting fire simply because of bracing style.
Seems odd to me. I always considered my data to be the important bits. Considering that some parts (eg./usr,/boot, etc.) can be mounted read-only on a stable server, I see a greater reason for/home and/var to be journalled. But then again, I journal everything since my network connection is usually slower than my hard drive access anyway.
Yes, in the 1950s, there was a lot of ignorance: excessive heavy metal pollution, "they're happy because they eat lard," duck and cover, etc.
However, the environmental movement -- which really got its start in the US in the 1970s (even Greenpeace is more than ten years old) -- has overcorrected. Now for them it isn't about the cleanest solution. It's about finding fault in any solution that doesn't feel right to them politically.
On a cost/environmental impact basis for large-scale power production, nuclear is damn good even when the waste is factored in. If coal, oil, and natural gas had to pay for any waste, pollutants, and harm through that pollution, they would be far more expensive. Solar and wind still require raw materials to build. Solar requires clean rooms for production. Both would require extreme amounts of materials to reach a majority of power production -- especially if the "hydrogen economy" comes to pass.
Wind isn't so bad (aside from the limited amount of wind available in large parts of the US), but could you imagine the semiconductor material necessary for solar: area larger than Connecticut and Delaware. And people complain about existing computer parts polluting groundwater. What happens in thirty years when all of those panels need replacement? That's a lot more material (by several orders of magnitude) than nuclear waste.
This is the crux of the matter: I am a nuclear advocate. I do not think that nuclear power is safe. I do not believe that any large-scale power production method is safe. I simply believe that the other options are worse.
The groups of tribes are the Shoshone and the Paiute. The Western Shoshone Nation are the ones most closely associated with Yucca Mountain. It's considered a place of powerful spiritual energy, but it is not a buriel ground.
The Shoshones and Paiutes are against it. Tribes in Minnesota (who have a nuclear dump site) and Utah (where an interim storage site is planned) are for it. The problem I see is that no one seems to have a better idea than Yucca. The only other "solution" I've heard thus far was to leave them in the hundred covered storage pools across the country. Strangely enough, you never hear about newer reactors designs like IFR/AFR which can process existing spent fuel and decommissioned weapons into shorter-lived isotopes. This would make either Yucca not needed or allow for only temporary storage instead of a 10,000 year design.
Of course bringing up Chernobyl is a red herring. First, no accident in the US has even approached Chernobyl. Second, the designs of US reactors is fundamentally different from Chernobyl in that a similar disaster is about as likely as a meteorite falling on your head. Third, Chernobyl was a weapons generation facility that had the beneficial side effect of electrical production. Fourth, the accident occurred because the fuel rods were being replaced while the reactor was in operation. Fifth, Cherobyl was a graphite moderated reactor -- graphite burns hotly. Sixth, the containment dome on Chernobyl was much thinner than those on US plants.
Some more facts on Chernobyl: It is located in Ukraine. Yes, the concrete sarcophagus is breaking down. They were supposed to be doing something about this and, contrary to your assertions, they are doing something about it. A larger, metal container is under construction. It cannot be built onsite for safety reasons. However a rail system is being constructed so that both halves can be transported once complete to enclose the site -- including the old shell.
"...even though it can easily affect most of europe..." That's a bold statement my friend. Care to back that up with some references? Various nations have been contributing money for some time now. Next you're gonna say that hundreds of thousands died in the accident. Scare tactics, nothing more. Hundreds dies, and their loss should not be belittled, but parts of Chernobyl are inhabited to this day let alone many surrounding areas. In fact, wildlife is flourishing. As is turns out, humans are a bigger threat to wildlife than radioactivity.
The nuclear industry (over)uses the word "clean" because organizations like Greenpeace (over)use the words "dirty" and "nuke." Classic overcorrection.
As for the discounts, could you provide a US source as our discussion up until this point was about US energy policy. US plants are not the same as Sellafield or Chernobyl. In fact, the Soviet plants were largely graphite moderated reactors whose primary purpose was weapon enrichment. Power was a side effect.
I'll need some citations from you on money as many of the references I find relate to stories of costs of decommissioning passed on to the consumer in the form of higher rates. This is in stark contrast to the UK. The US federal government also insures companies for injury claims that exceed a certain threshold. Thus far, this spillover account has never been tapped.
Of course subsidies for solar and wind are easier to find, but you won't hear that from the anti-nuclear camp very much.
Slashdot Mirror
I didn't say it had to stop. Granted pg_dump slows a system down, but the whole point was to allow hot backups.
That said, I get what you are saying, but in that case, how do you upgrade *anything* (and why)? What happens when a drive fails in your RAID? Do you wave your hands and wail because the speed has dropped during the array rebuild? How do you add drive space, memory, CPU power?
Really what you seem to be lacking, as other posters have mentioned, is redundancy in your database. Granted you will be back to a couple of days for the complete transition, but you are asserting a requirement that 90% of us do not need. Nevertheless, the synchronization option is relatively pain free and allows for the 24/7 uptime you require.
For the rest of us, it'll just be a few (ungodly at 3am) hours at most.
How complete is the API? The power of the Java and .NET VMs (I don't know Parrot well enough to comment) is their standard libraries -- perhaps to a larger extent than the bytecodes themselves.
Array bounds checking is not new. Dynamically loading code isn't new. What was new was the creation of a standardized toolkit and API that handled threading and network I/O and GUI and database access and XML parsing and... You get the picture.
Another portable VM holds little value for me if in the end I just end up back to the "good ol' days" of C where you were given a hammer and told to build a house. POSIX isn't enough.
Static electrical discharge is not necessarily just because one item has an excess (or lack) of electrons. It is because the two points in contact have a substantially different charge. Both items could have an excess of electrons, but if one item has substantially more, there is still a discharge.
That said, it was the "paint." The Hinderburg was draped in cloth. Cloth is inadequate in itself to contain hydrogen, so one must dope it (or paint it, but that implies a different purpose). That "paint" was essentially rocket fuel. In addition to being highly flammable/explosive, it also seals cloth so that it can contain hydrogen.
So, charge differential + arc + rocket fuel = burning airship.
The Hindenburg caught fire because the cloth it was covered in was doped in what amounts to rocket fuel. The disaster had little to nothing to do with the hydrogen. A charge differential between the tower and the Hindenburg created a spark and ignited the outside covering.
If it had helium instead of hydrogen, it still would have gone up in flames.
You mean that same ISAM format that doesn't support transactions, foreign keys, etc.? That ISAM table format?
In other news, if you can't make a dump of your database, how are you doing backups? You are backing up your database, right? Right? If it's a space issue, how about spending $130 for 200GB on a separate box for temporary storage? And days? C'mon! What are you using? A 233Mhz Pentium with a single IDE drive also doubling as a fileserver?
And finally, don't dump to SQL.
pg_dump --format=c
Faster; Smaller; More efficient.
No arguments from me.
If you are competent enough to set up a database, you're competent enough to use escaping/unescaping functions.
That said, to make it transparent, just set a trigger and a view. Create a trigger on insert or update to the table in question to run the escape prior to saving to the table. After you've done this once, insert and update as normal from now on. Create a view that selects on the unescaped value. After you've done this once, select from the view as normal from now on.
It's nice that PostgreSQL allows folks to work around these "issues." I don't blame you for not seeing the possibility that people wouldn't want or care about escaped binary data in their database. With MySQL, failure to see possibilities is commonplace. Like for example the fact that triggers and views are probably unknown to you because MySQL doesn't have them. But even though they easily and elegantly address your "problem," I guess they're just "nice extensions."
And for the record, "data" is a piece of information. "Database" is the collection of information -- the collection of data. Storing data is an important task for "database management systems." All the search and calculation features are the raison d'etre.
No more than Perl and Tcl are prerequisites. As with all programming language support in PostgreSQL, you compile what you want in and exclude what you don't want.
Calm down. Breathe.
Apparently you've never been so poor as to live hand-to-mouth or worry about where rent money is coming from. During those times, if it weren't for the fact that I couldn't afford health insurance, given the choice I would have rather been injured (as long as it wasn't a permanent maiming and rent was covered) than be broke.
As we know, in the real world being injured and broke are far more commonly bedfellows, but that wasn't the hypothetical choice presented.
Money doesn't matter as much to those who have it. To those without it, it's one of the only things that always matters.
In addition, until there is such a study, whatever seems to work for a development group is what they should use. If 105 characters works for them, they should use it. I never stated to the contrary.
In the end, I think we agree. Personally, I aim for 80 characters, but if the statement cannot easily be broken up and can be understood easier on a longer line, so be it. In other words, as I said in my previous post, I'm okay with guidelines for line length, but I'm against hard limits.
By the way, what compilers do you use that have line length limitations? Seems pretty lame to me. '\n' is just another character. Then again, so is '\t'. So technically, five indents only raise the number of characters by five. But now I'm just fucking with you.
Pixel for pixel, no it doesn't. Width of blocks via <table width="*"> or CSS's "width" property? HTML most certainly does guarantee this. On text browsers, the console width is the limit. On every browser newer than Netscape 4 -- >95% of the browsers out there -- the CSS property "width" is supported with sufficient correctness to constrain text. The table element covers 99.999%. HTML doesn't need to guarantee how the whole page looks and renders. For the purposes of this conversation, it only needs to guarantee that the texual line width does not exceed a certain value. In this respect, it absolutely guarantees.
HTML is not supposed to? Fine. I can accept that. CSS is supposed to though. Which brings me back to my original -- and I think completely justified -- point: a page that advocates an 80 column limit should not have its own text width unbounded.
Point taken. Then again, Indonesia, Pakistan, and North Korea are all examples of countries with unhealthy aspirations for power and/or blood enemies (Pakistan/India, North Korea/South Korea, North Korea/EVERYONE).
Granted. You win on this one.
Got any links? What are the energy yields?
Which is fine, but you're still talking about surface area and the Solar Constant. Whether that 1.367kW/m^2 is in electricity or manifests itself in thermal heat, it is still a very diffuse energy source. But I think I get your point. Passive solar heating in the home (for example) can reduce energy usage dramatically.
Pound for pound, I'm not. What I was suggesting was that a Connecticut and Delaware of used solar panels is a lot more material to deal with than the equivalent amount of nuclear waste in the same time if breeder-burner nuclear reactors were used. Then again, if existing spent fuel were diffused over as much material as the hypothetical solar panels, the ambient radiation wouldn't be substantially higher than background. There's still the issue of small transuranic particles if they were to enter the lungs, but radon in homes is a more pressing general health concern in my opinion. I don't believe "all chemicals are bad." I also don't believe that "nuclear is warm, fuzzy, and cuddly." When I said, "clean," what I meant was "lower ecological threat when compared to oil, coal, and natural gas as measured in volume and toxicity of pollutants released into the environment." I should have been more specific. I will try to avoid the overused term "clean" from now on.
As for the advertisements and sound bites, I haven't seen many. I grew up and live in a very anti-nuclear part of the country. In fact, most of the people I speak (argue) with fail to distinguish between nuclear power and nuclear bombs. In fact, I used to be vehemently anti-nuclear myself. Then I met someone who graduated with a degree in environmental engineering -- who was also anti-nuclear -- but needed a job and went to work at the Diablo Canyon nuclear facility. He took the job with the agenda of blowing the lid off any coverups and gross mismanagement. Instead he became a nuclear advocate. Years after he left that job and went to work in the software industry, I met him. He was kind enough to go over the halflife radioactivity curves with me. He pointed out to me various sites for information that were not tied to PR arms of the nuclear industry.
Later I came to live with someone who used to work at various power plants around the world, both nuclear and non-nuclear. It was through sources away from the headlines that I came to be a nuclear advoc
The current generation of PVs basically all require clean rooms to make. While there are some that don't, by and large they either don't have a reasonable lifespan (measured in months) or power output or both.
But you're right. If we hit that break-even point within the lifespan of the components, it will probably be worth it. I just have a hard time seeing 3.8W as anything useful unless it cost less than double-paned glass -- what I see as its greatest market competitor.
I have to admit, you have me wanting to take a closer look at white LEDs for the home. Got any links besides the overpriced VOS Pad? Thanks.
Now, back to code. If your shop standardizes on 105 characters for line length, more power to them. I never said it was a bad thing to standardize a shop's code. What I called into question was a universal belief that 80 characters is somehow a holy construct. Once again, show me the study that compares readability of code and not prose, and I will listen with both ears. Until that happens, you are making the ASSUMPTION that since prose is this way, code must be as well. I do not believe this assumption to automatically be true. It may be, but in my experience, an arbritrary 80 character limit can harm readability rather than help it. Now if you had advocated a 80 character guideline -- rather than a hard limit -- I would be more receptive. Then again, if you advocated a "one statement/one line" approach, I wouldn't be against it either.
Funny, I thought the whole point to HTML (and CSS) was to format information for display. Some web sites have one sidebar. Others have two. Some have none. If sites are not consistent with width, how can a browser be "comfortably sized." This is an abdication of responsibility. If you're responsible for development of a web site, you are also responsible for making that information as easily absorbed as possible. Often times, it may be at 80 columns (or x pixels or y centimeters), but not always.
But then, it is this situation that the CSS property "width" was created for. Or <table width="x"> if you still misguidedly code pages that way.
The first is labor intensive and prone to forgetfulness when someone just wants to put a few patches in. The second is a royally bad idea as what you are checking in is not what you were working on. Most of the time it won't be an issue most likely, but it breaks a fundamental source control rule: test before you commit. To put rigor back in, you have to make the code changes, test it, put it through the formatter, test again, and then commit. You don't want to format at the first step because you're still working on it in your own formatting choice. The only other choice is to test redundantly.
No one said that you had to change. If most of the people on your team prefer your method, then stick with it. I think of source in this case like insurance forms (or some other form).
You can have no end of formatting choices for those forms. All of the forms can have basically the same information. However, when looking through all of these forms for certain bits of info, if all of the forms are different or if you have four or five different formats, finding that information becomes harder for the human eye/brain. If all of the forms are of the same format, if the information being looked for is in the same location each time, searching is faster, easier, and more reliable.
This is of course a loose analogy, but let me put this into more concrete terms: the Java source standard.
lowerFollowedByMixedCase = property
lowerFollowedByMixed() = method/function
UpperFollowedByMixed = class
foo.doSomething() = instance method
Foo.doSomething() = method at class scope
Foo.ALL_CAPS = a class constant
In other words, without knowing anything at all about the code, I can look at any Java code following this standard and know where to look next. I know whether something is an instance variable or a class declaration. This is something that is sorely missed on the C, C++, et al. end of things. No, I'm not saying that mixed case variable naming is the best. I like it, but not everyone does. That's not my point. My point is that with consistency comes the enhanced ability to spot check code that others wrote (and that I wrote six months ago). It allows for faster and easier understanding of code.
Braces are a minor addendum to this point. Yes, they are relatively unimportant. But they are also easy to adapt to. When in doubt, err on the side of ease of reading.
Braces can be formatted easily. Many other things that are useful for code comprehension cannot. I'm not talking about more strawmen like "banning protected members because they don't fit the code guidelines." I never said a thing about reducing the toolset available to coders. Your job as a coder is to get it working. Bracing style has NOTHING to do with getting it working whether the brace is on the same line or not. It has to do with consistency and readability. And just as with comments, these things should not be tacked on at the end as an afterthought.
Switching brace style is basically instantaneous for me. For most others, it may take part of a day. For the really slow ones, it may take a second day. In any case, it takes less time to learn to do this than it takes to use a formatter over and over again. Yes, the formatter only takes a second or two, but you're advocating it's use for every piece of code you work on.
Yes, I know the reason: unified installer for all supported platforms. That simply tries to justify the difficulty. It doesn't make the difficulty go away.
That said, I'm a loyal Debian user. I hate putting it on a box, but once it's on, I have no real complaints.
So for $45 * 95 square feet, you can run the VOS Pad LEDs. Of course, I acknowledge that you pointed out that this is when all lights are on full. What you failed to mention was that the VOS Pad costs £35,000 (about US$52,500). This is not practical. The return on investment would likely take the better part of your life -- if even that short. Sure, it could take this portion of your energy consumption off the grid, but how much energy was required to make these materials in the first place? How much energy was used by the manufacturing facilities? At a price of £35,000, you can bet it isn't peanuts.
As for OLEDs, yes they look promising. However, until they actually hit mass market, we don't know actual numbers. Looking at this press release, Samsung's 17" display "will consume no more power than a 15-inch display..." Sure you can take away the backlight, but this is not the same as slashing the total power consumption. Reduces it, yes, but doesn't make revolutionary drops. On the bright side (no pun intended), OLEDs have the potential for cost savings.
You're right. We should attack it from both ends or at least leave everything open as possibilities. However I still believe that I was right. We should not concentrate on technologies that only provide marginal improvements for the amount of money/resources spent. We shouldn't ignore them of course, but we definitely shouldn't fixate upon them. We have a limited amount of resources and money. For better or for worse, this is the reality of our world: scarcity and commerce.
Who cares if my electricity bill is reduced by half or even eliminated entirely if the initial cost in materials exceeds what I would pay in electricity for the next fifty years?
If a solution presents itself that uses more resources or costs substantially more than our current methods, it is not a good solution. In some circumstances I could see this PV glass making sense. In most scenarios though, I see it as a curious novelty that makes little sense for the average Joe like myself.
As I look out one of the windows in my bedroom, I estimate that the 2.5 by 3 foot window would cost me around $337.50 to replace just the glass. (I'm sure the framing would add to the cost.) I have three such windows in my bedroom. For some odd reason, I think my money would be better spent on double-paned replacements and using the money saved on both initial investment and heating costs to pay for my energy bills until the technology improves in a few years.
At $45/sq. ft., the $1,012.50 (at least) I would spend on three PV glass windows would not be recouped anytime soon. I like to think of myself as an optimist, but I'm not that blindly optimistic. Assuming 22.5 sq. ft. of PV glass, 3.8W/sq. ft., 7hrs of useable sunlight a day for 22 sunlit days a month (on average), I get a little more than 13kWh (kilowatt hours) per month. Let's say I pay about 10 cents per kilowatt hour -- pretty expensive I think. This means I get back $1.32 every month from these windows. Woohoo! I will have paid for them in 64 years! Well... That's assuming they last for 64 years.
At first, I read it as 3.8kW and said, "Hunh? That's more than the Solar Constant, 1.367kW per square meter." Then I reread it and saw that it was simply 3.8W. This sounded much more reasonable... and small.
This means that a 60W light bulb would need almost 16 square feet to function. Well, that of course is a reason to move to compact flourescents or LED light bulbs. But my computer takes up a bit of power. So does a refridgerator. So does a washer/dryer.
Let's say that it is a television. What's the equivalent of a square foot display (asuming a 5:4 ratio)? About 13"? Can a 13" LCD display work with 3.8W of power? (I don't know. That's why I'm asking.)
I'm not questioning whether it can give power. I'm questioning whether it can give sufficient power to offset the price. Or would the money be better spent elsewhere in green technologies to reduce the actual draw from the grid?
All of those studies you referred to are speaking of prose. If anything, they speak to having 80 column multi-line comments.
Show me a study that compares code at 50 columns, 80 columns, 132 columns, and 200 columns and you'll get my full attention.
Also of note: the first link which advocated shorter line lengths is on a page with unlimited line length.
So tell me. How much should I respect you if I am your boss? You've just told me that despite the myriad choices and possibilities available in programming that you cannot adapt to a simple change in bracing style.
If it takes you more than a week to get accustomed to a new formatting style, you will forgive me if I doubt your ability to adapt to a new compiler or new editor or new operating system or development library.
And please stop with the strawman of forbidding polymorphism. Yes, there are moronic shops that forbid certain practices that can be instrumental in solving certain problems. But the parent clearly wasn't talking about those instances. This wasn't a discussion of functionality, it was about aesthetics. Deciding about the amount of whitespace, the capitalization patterns, the bracing style, and the line length do not fall under your diatribe.
And frankly, if you cannot adapt from
if (1) {
}
to
if (1)
{
}
to
if ( 1 )
{
}
or from
write_file()
to
writeFile ()
to
Write_File( )
your problems extend far deeper than your code style.
The question boils down to, "Which formatting style is best?" The answer is simple: "Whatever everyone else on your team is doing." If you cannot adapt to something as simple as this, you cannot be effective in a team. If you cannot be on a team, you are fundamentally useless to 99% of all projects out there. There are better ways to express yourself in code than through bracing style. If formatting style is the best way you can assert your skills and individuality, what does that say about your skills as a programmer overall?
Have a nice day.
16? With all of the choices available to code with -- languages, libraries, operating systems, compilers, etc. -- your main gripe is bracing style? Are you fucking kidding?
Let me put it this way. Let's say that I'm a prospective employer. I'm looking for someone with a good head on their shoulders, that works well with a team, and can adapt to new situations. Then I hear you say the above statement. So far, what I know of you is that bracing style is a religious doctrine for you, you will not respect any preferences but your own, you will waste time bitching about a coding style instead of getting work done (the "spit fire" comment), and you expect that a codebase could or should have more than one coding style in it -- that or "my way or the highway."
Most employers want someone who works well in a team. "Team" usually implies working together toward a common goal. It requires some uniformity in process. But you aren't even willing to be swayed by something as trivial as bracing style. You probably have an enormous opinion of yourself and yet cannot adapt to a perfectly valid and trivially different coding style.
Nice.
The sad part is, you're useless to both commercial and Free Software camps. Commercial software won't like you for the above reasons. Free Software projects all have different idioms and coding guidelines. Imagine their chagrin when some hotshot comes in and starts spitting fire simply because of bracing style.
Grow up. Learn to adapt.
Anyone here old enough to remember Microsoft's new operating system code named Cairo originally scheduled to be released in 1992?
Same story, same hype, new code name.
Seems odd to me. I always considered my data to be the important bits. Considering that some parts (eg. /usr, /boot, etc.) can be mounted read-only on a stable server, I see a greater reason for /home and /var to be journalled. But then again, I journal everything since my network connection is usually slower than my hard drive access anyway.
Yes, in the 1950s, there was a lot of ignorance: excessive heavy metal pollution, "they're happy because they eat lard," duck and cover, etc.
However, the environmental movement -- which really got its start in the US in the 1970s (even Greenpeace is more than ten years old) -- has overcorrected. Now for them it isn't about the cleanest solution. It's about finding fault in any solution that doesn't feel right to them politically.
On a cost/environmental impact basis for large-scale power production, nuclear is damn good even when the waste is factored in. If coal, oil, and natural gas had to pay for any waste, pollutants, and harm through that pollution, they would be far more expensive. Solar and wind still require raw materials to build. Solar requires clean rooms for production. Both would require extreme amounts of materials to reach a majority of power production -- especially if the "hydrogen economy" comes to pass.
Wind isn't so bad (aside from the limited amount of wind available in large parts of the US), but could you imagine the semiconductor material necessary for solar: area larger than Connecticut and Delaware. And people complain about existing computer parts polluting groundwater. What happens in thirty years when all of those panels need replacement? That's a lot more material (by several orders of magnitude) than nuclear waste.
This is the crux of the matter: I am a nuclear advocate. I do not think that nuclear power is safe. I do not believe that any large-scale power production method is safe. I simply believe that the other options are worse.
The groups of tribes are the Shoshone and the Paiute. The Western Shoshone Nation are the ones most closely associated with Yucca Mountain. It's considered a place of powerful spiritual energy, but it is not a buriel ground.
The Shoshones and Paiutes are against it. Tribes in Minnesota (who have a nuclear dump site) and Utah (where an interim storage site is planned) are for it. The problem I see is that no one seems to have a better idea than Yucca. The only other "solution" I've heard thus far was to leave them in the hundred covered storage pools across the country. Strangely enough, you never hear about newer reactors designs like IFR/AFR which can process existing spent fuel and decommissioned weapons into shorter-lived isotopes. This would make either Yucca not needed or allow for only temporary storage instead of a 10,000 year design.
Of course bringing up Chernobyl is a red herring. First, no accident in the US has even approached Chernobyl. Second, the designs of US reactors is fundamentally different from Chernobyl in that a similar disaster is about as likely as a meteorite falling on your head. Third, Chernobyl was a weapons generation facility that had the beneficial side effect of electrical production. Fourth, the accident occurred because the fuel rods were being replaced while the reactor was in operation. Fifth, Cherobyl was a graphite moderated reactor -- graphite burns hotly. Sixth, the containment dome on Chernobyl was much thinner than those on US plants.
Some more facts on Chernobyl: It is located in Ukraine. Yes, the concrete sarcophagus is breaking down. They were supposed to be doing something about this and, contrary to your assertions, they are doing something about it. A larger, metal container is under construction. It cannot be built onsite for safety reasons. However a rail system is being constructed so that both halves can be transported once complete to enclose the site -- including the old shell.
"...even though it can easily affect most of europe..." That's a bold statement my friend. Care to back that up with some references? Various nations have been contributing money for some time now. Next you're gonna say that hundreds of thousands died in the accident. Scare tactics, nothing more. Hundreds dies, and their loss should not be belittled, but parts of Chernobyl are inhabited to this day let alone many surrounding areas. In fact, wildlife is flourishing. As is turns out, humans are a bigger threat to wildlife than radioactivity.
The nuclear industry (over)uses the word "clean" because organizations like Greenpeace (over)use the words "dirty" and "nuke." Classic overcorrection.
As for the discounts, could you provide a US source as our discussion up until this point was about US energy policy. US plants are not the same as Sellafield or Chernobyl. In fact, the Soviet plants were largely graphite moderated reactors whose primary purpose was weapon enrichment. Power was a side effect.
I'll need some citations from you on money as many of the references I find relate to stories of costs of decommissioning passed on to the consumer in the form of higher rates. This is in stark contrast to the UK. The US federal government also insures companies for injury claims that exceed a certain threshold. Thus far, this spillover account has never been tapped.
Of course subsidies for solar and wind are easier to find, but you won't hear that from the anti-nuclear camp very much.