MySQL is about the fastest dbms out, which isn't always a good thing if it trades atomity for speed...
SQLite is faster and supports atomicity. It slows down with multiple concurrent connections, but then so does MySQL. In the case of many simultaneous and concurrent connections, you want to look at PostgreSQL if a free database is on the menu.
And no one is trying to force them into caring what I think. I simply stated my opinion: it's a waste of time to reinvent an obsolete wheel. Take the advice or don't. That has no bearing on me airing my opinion.
1. The conversion from RCS to CVS is not necessarily seamless. 2. As Subversion whole reason for existence is to "fix CVS once and for all", there are migration tools to switch with.
The Apache Software Foundation has been steadily moving their revision control to Subversion and they have a *huge* amount of code. No one is suggesting you scrap everything you've got and starting over from scratch.
They take what amounts to a standard set of hacks on top of RCS. Then they make a port of it with a BSD license. Then... we're supposed to believe this is a good thing?
Subversion and arch would be better models wouldn't they? Hell, subversion has an Apache-style license to it. Closer to BSD than GNU CVS's GPL *and* Subversion is better than CVS right now.
I'm more than grateful to the OpenBSD project for their work on free firewall implementations, openssl, openssh, etc. But enough's enough. CVS? Aim a little fucking higher guys!
Apache takes >15 seconds to start? My god man, what are you running? My house server is a 1GHz Athlon and I basically don't see the startup -- I'm serving WebDAV pages (via Subversion and Apache2) from a cold start in less than a second. Even on a 486, it shouldn't take even close to 15 seconds just to start up. Reduce the MinStartServers settings for example.
Another note, are you running out of memory on the box? Unless you're using up >95% of available memory (and thus beginning to swap heavily), what does it matter?
As for RSS (and ps reports in general), don't believe everything you read. When Apache forks processes on a good OS, a copy-on-write occurs. This means that unless a particular page of memory actually changes, a child process allocates no additional RAM (simplification of course, but effectively true). In addition, older versions of ps and some OS kernels report threads as separate processes. I'm running Apache2 with the worker MPM on a Linux 2.4 system and it looks like a dozen processes taking the same amount of memory instead of one process with a set amount of memory.
And then of course there's the issue of memory allocation vs. memory usage. Many processes (not just Apache) have pages swapped out because they aren't actively used.
So after all that, are you sure that Apache is taking up as much memory as you believe? And are you hitting swap -- the real memory litmus test?
Sometimes I really hate comments like this. Just how heavy to you think Apache is? With PHP/Perl/Python/Kitchensink support loaded in, sure.
Try loading Apache with just the barest essentials of modules (core functionality in Apache 2). The resource footprint ain't very big. Also, in terms of speed, Apache 2 can use the sendfile(...) API, memory map resources, and mod_cache if you load in support for it. In this configuration, you can easily saturate a gigabit ethernet connection. So unless you've got a gigabit internet pipe, use of thttpd vs. Apache is a moot point.
And besides, if raw web file serving performance is your goal, your script algorithms, internal caching model and judicious use of reverse proxies will make far bigger differences than your choice of web server.
Now then, on to WebDAV. Your comment, "Are there any small, light tools that will just do WebDAV and nothing else, that I can add to my setup?" belies a fundamental ignorance of what WebDAV is. It's an HTTP layer for file handling. By definition, anything that "will just do WebDAV" will need to be a web server. Subversion has it's own transport, but prefers the use of Apache for access to its version control repository. Why? Because Apache handles HTTP well. Why reinvent the wheel?
So in summary, in order to use thttpd with WebDAV, you would need to use thttpd as a proxy to another web server that also handles WebDAV, or you can get someone to write extensions to thttpd so that the WebDAV HTTP extensions PUT, DELETE, MOVE, PROPFIND, LOCK/UNLOCK, etc. are implemented correctly. Of course you would just be rewriting Apache+mod_dav, but suit yourself.
Hmm. Mentioned the W word. That is another thing I don't touch because of too many bad experiences. No other comment.
So why worry about cross-platform GUI inconsistencies? If you're only using one platform, it doesn't matter one way or the other. I question both the socially redeeming quality and the business sense to coding to the exclusion of >90% of the desktop population, but suit yourself. (I guess this is why I've shifted so heavily toward web applications. Windows development without having to even look in the general direction of MFC or OWL libraries.)
For the record, I think a purely C or C++ desktop app on any OS is an absolutely horrible design decision from a security standpoint.
Regarding Sun's monetary woes, I don't know if they make enough money off of Java to cover their related costs. I imagine it does. It's their hardware and Solaris divisions that have performing so poorly lately. I know IBM does cover their Java-related investments easily. Being such a pragmatic company, I know that they didn't, they would have dropped it like a hot potato years ago.
They ain't using it for love of Sun, I can tell you that.
I'll try showing things from my point of view. I have been co-hosting a weekly science and technology radio talk show for the last four years. Right now we put the show archives on the web so people can listen at their leisure. But MP3s aren't so hot for dialog. To get voices to sound good, you have to up the bitrate which in turn ups the bandwidth usage.
So I researched around and found Ogg Speex. Even at low bitrates, speech sounds great. So at a smaller file size than MP3, I can get better quality for my listeners. Everybody wins, right?
Well, the codec has a problem. There isn't a uniformly good decoder for Windows, OS 9, OS X and various Unixes where I can just point someone to a URL and have them hear anything interesting -- unlike MP3. So what about a Java applet? There's a Speex decoder for the JavaMedia API. (An Ogg Theora as well, but I digress.) With even an older JVM on the system, codecs can be downloaded as needed. And after the user has left my website, no trace remains. Nothing to install and nothing to uninstall.
But...
There are quite a few people out there who refuse Java "on principle". My website is for a radio program. Audio is an intrinsic part of the overall equation. So what are the alternatives?
It's not that I think Java is perfect. It's that for many tasks, it's the best tool for the job.
As far as ActiveX goes, my hatred of it is a different animal than your hatred of Java. I cannot and will never trust ActiveX precisely because it's native code. You cannot build a code sandbox around a technology that allows direct pointer manipulation. Period. The use of ActiveX in all but the most rare intranets is absolutely unforgivable in my opinion from a network security perspective. Then of course we get into the fact that ActiveX only works on one browser on one operating system on one type of hardware -- quite the anathema to the original spirit of the internet. None of these items is true of Java. The worst indictment of Java is that it has been slow and people have used it for ad banners.
You hate Java for how it's been used. I hate ActiveX for what it is, its underlying design. There's a fundamental difference there.
Regarding NullPointerExceptions -- any unchecked exception for that matter -- and the end-user/developer divide, I couldn't disagree more. Developers get their bug reports from end-users. Stacktraces, being text, fall into log files easily. These log files get emailed to developers in "incident reports". Core files don't fall into log files quite so easily. Printable stacktraces with line number references was one of the best things to happen to the client-debug-patch loop in the software arena. Released binaries with debug symbols stripped out (as is common in shipped software) can be an absolute nightmare when trying to replicate in-house.
If it helps the developer fix bugs, it by definition helps the end-user and is therefore just as relevant to the end-user.
As far as ad banners go, the same technology used against Flash and Gif/Jpg ads could be applied to Java applets as well. The Ad Blocker extension to Firefox comes to mind. By default, all plugin or suspected ad banner activity is blocked from view unless you specifically enable it on a per-site basis. As far as if a complete site is based upon Flash or Java (a horrible design decision 99.9% of the time in my opinion), the simple answer is to avoid the site in the future.
I guess what I'm getting at is that there are technological solutions to these problems, but just turning it all off is akin to throwing the baby out with the bathwater.
You would guess wrong. I have coded for appservers, applets (where I started with Java), and standalone applications. AWT since the 1.02/1.1 transition and Swing since the 0.5 beta.
Yes, there are differences in rendering on different platforms -- mainly the sizes and shapes of native widget peers. I have also had FAR more problems getting GTK+ to work on X and Windows. It's like nitpicking that HTML isn't crossplatform because h1 tags use a different default font and sizing depending on the browser/platform. HTML addressed it (mostly) with CSS. Java addressed it (mostly) with the metal UI. They are issues, but far and away less of a problem than alternatives. Are you honestly going to try to tell me that Java is inferior to millions of #ifdef statements? Please.
Oracle installers aside -- and that argument holds little water with me since Oracle had crap JDBC drivers for years too (evidence of bad programming, not a bad programming environment) -- I have had very few inherent Java problems. The web plugin has been extremely stable in my experience. Server apps have been as stable or more so than many of their C or C++ counterparts. I can't remember the last time I heard of a Java app allowing a remote exploit by way of buffer overflow.
As for the statements "Perl works" et al., you haven't left the traditional UNIX world lately have you? Go to Windows and you'll find out how many vaunted CPAN modules were written for UNIX only. Go to OS X and tell me how easy it is to install the Python Imaging Library, a very common dependency for many apps. Done much debugging of C++ where templates (including the STL) are used extensively? Nothing "just works". Chances are the things that "just work" do so because the environment was set up for you already in the distribution. Yes, this is largely because the JDK/JRE aren't allowed to be redistributed with the operating system in most cases. Yes, this is the biggest reason why Java should get a more liberal license. But there is nothing inherent to the VM setup or libraries that makes it inferior to the others.
java -jar myapp.jar
Works for me. If a standalone app can't be started reliably like this, blame the program author, not Java. The Java plugins come with the JRE. Make a symbolic link to the browser's plugin directory. Done. All users on my multiuser server have the plugin installed. Run the JRE installer on Windows. Done. All users on the XP box have the plugin installed. I don't why it's been so hard for you when it's been so much easier for me.
This isn't even like when your kids are out on their own. They're in the house. There are no hard and fast rules for how long is too long, but if you think the line is being crossed, walk over to the computer, reach behind the back of the case and pull the power cable.
If your teenager is spending too much time on the telephone, pull the cord out of the wall.
That said, make sure you know what your kids are doing online. No, I don't mean spying. I mean are they IMing their friends, IMing some letcher or learning how to program? Are they "wasting time" on howstuffworks.com or incessantly playing Doom3?
And make sure that you periodically kick them out of the house to play soccer.
Exactly! And another aspect that people can't seem to wrap their heads around is the lack of confirmation windows in Java client-side. Sure a signed applet that will be accessing the local filesystem or connecting to an arbitrary server on the net will pop up a dialog box as it should, but normally it just starts up and runs.
ActiveX pops up a dialog box at every new instance on every site. The user ends up thinking, "Oh, another damned popup," and just clicks on it. It's like email and dealing with spam. There are so many junk emails, eventually you make a mistake accepting one you shouldn't have or dumping one that you would have wanted.
With the Java applet sandbox, only actions that are potentially dangerous require a confirmation dialog, and 99.9% of all applets do not need signing. Sure, today Sun announced a vulnerability. That makes how many in the last ten years? Seriously, compare that number with the number of exploits in basically any network-aware program in any language. Dumping Java over this is like refusing to go out to restaurants anymore because a friend of a friend got food poisoning.
You want to be absolutely safe, unplug your network or modem cable. There you go. Absolute network safety. Life is a compromise.
But since the jre is so finicky and broken, its not worth it to use the language, no matter how good it is.
I have two problems with this. One is that I've been coding in Java for years and yet I find no more bugs than I come across in common C or Perl libraries. As for finicky VMs, I wonder if you'v ever actually pushed the Perl and Python VMs over the years. Those have not been without their fair share of bugs.
Problems with CLASSPATH? Right. Like people don't have many of the same problems with PATH and LD_LIBRARY_PATH. Your problems are inherent in splitting programs into modular pieces, not with Java specifically.
As for a multiuser system and Java, I've been doing it for years. Wasn't all that bad. You have a wrapper script in/usr/bin right? Handles all my classpath and pathing issues in one fell swoop with users just typing "java" at the command line.
My browser has _no_ plugins running by default. Also, my browser (Safari) has a separate Java and plugin preference checkbox, and I rarely load Java. The last time I did was to look at some buggy applet that someone wrote at work.
Over the years I have come to dispise Java. It would be different if it worked, but for me, Java has caused many problems, and I have seen 0 benefits from it.
So you have plugins including Java applets turned off but then say you haven't seen any useful applets. So let me get this straight: you hide them and then complain that you can't see any good ones. Self-fulfilling prophecy? By that metric, do you drop all usage of OS X if you come across a badly written program on the Mac? Starting the plugin the first time is slow, granted. But I've been running Safari on a 500MHz iBook and Java applets haven't been a problem for me. The best written ones have been the ones where I almost didn't notice they were applets. Well-written ones are like this. A lot of folks who denigrate Java out of hand have come across good applets but not recognized them as Java.
I've had Netscape crash at least on the order of hundreds of times because of Java.
Have you used Java since the old Netscape days? The plugins in IE, Mozilla, Firefox and Safari have not caused me any problems in years. I find it hard to believe that I've just been the only person in the world and/or am extremely lucky.
Well... except for that one applet that was a site logo rippling like it was underwater. Pure eye candy that sucked up 60% CPU time sustained on a 3GHz processor. Once again, good technology, bad applet writer.
That said, I prefer DHTML and related technologies to visual Java applets these days. In a better world, I would have the UI handled by the browser's renderer and the logic handled by Java. Javascript is nice and all, but sometimes you want to do some heavier lifting. And I sure as hell am not going to use ActiveX for that even if it was supported on non-IE and non-Windows environments.
And I too am talking from experience as I have developed on Java on Windows since Win95, OS/2 Warp, Novell NetWare, Solaris, OS X and Linux. Applets, servlets, EJBs and standalone apps. Aside from filesystem path differences, I have had maybe two problems in the last seven years moving my code from one platform to the next. And yes, I can code in C (K&R and ANSI) and C++ (including ISO98) too. Learned them before Java, so it's not because I haven't seen any other platforms.
By the way, your mention of NullPointerException is funny to me. Take a C app and access a null pointer. Boom! Hope you have core files enabled so you load the image in a handy debugger. Take a Java app and access a null reference (pointer). Not only can the exception be caught so that it doesn't completely take down the app, but you get an easy to read (relative to C and C++) stacktrace telling you exactly where it occurred so that you can fix it.
It's not the only language in the world and definitely isn't the only language you should have in your toolbelt, but it doesn't deserve the maligning you just gave it.
A leak of 640 kg of non-radioactive sodium from the MONJU secondary Loop C occurred on 8 December 1995 while the reactor was operating at low power. The liquid sodium, which ignites on contact with air, caused damage to a ventilation duct and an access walkway grating. Sodium combustion residues were spread over a large area of the Loop C rooms and some escaped outside the building. The reactor was shut down manually and remains in the shut-down state pending a review of safety and possible plant improvements. During the accident there was no loss of cooling to the reactor, nor was there any danger of the fire spreading to the reactor and primary systems or other secondary loops. No injuries or exposure to radiation occurred. There was no effect on the environment.
The accident has classified as Category 1 on the international scale of 0 to 7 by a committee of independent specialists.
Unless my conversion tables are totally off, 640kg is not 2lbs. Also, pay close attention to casualty reports.
Deaths: zero Injuries: zero Exposure to radiation: none Effect on environment: nothing
Yeah, sounds like a catastrophe. Read all about the accident here. It's really fascinating. They look at what happened. They found out why it happened. They designed a new part to make sure it never happens again. The safety analysis and manufacture of this new part is a major reason why the plant has remained offline for so long. Yeah, those nuclear engineers are reckless. (sarcasm)
Yes, I'll grant you sodium requires special handling. You know what? So does sulphuric acid. So does gunpowder. So does phosgene, monomethylamine, methylisocyanate and the pesticide carbaryl. You want to eliminate the handling of toxic, carcinigenic, flammable and explosive substances? Get used to a lifestyle similar to a Bangladeshi sheep herder. See those papers on your desk? These required the tons of chlorine sitting in train cars outside the paper factory.
Sodium is just one of many potentially bad things that can be used to enhance our lives. So what happens if the sodium leaks? Well, the sodium helps neutron flux in a fast reactor. You take away the sodium, the core will likely go subcritical (shut down). If not, the fuel might partially melt. Still won't cause a problem. Then maybe there is some malice or gross negligence and someone allows a rush of oxygen and/or water into the core igniting the sodium and causing an explosion. Still won't crack the protective dome on all modern nuclear reactors. So even in the event of a catastrophic series of highly unlikely situations, you're still not likely going to affect anyone except the energy company's pocketbooks (and the customer as the costs get passed down). So it's in their best interests to play it safe and put in safeguards to substantially reduce the risks.
Contrary to popular belief, nuclear plant design didn't stop in the 70s. Today's new designs don't rely on trained operators, computer controls, pumps, or valves. They are designed so that if anything goes wrong, the natural state is to shut down. This means relying on things like heat convection, thermodynamics, electromagnetism, and my personal favorite, gravity.
Think about this: Q. What was the worst nuclear accident in US history? A. Three Mile Island
Deaths: zero Injuries: zero Effect on environment: nothing Exposure to radiation: ~80mrems (normal background radiation is 250mrems)
And yet if you ask people about TMI, they will say this was considered a horrible accident. The chemical plant accident in Bhopal, India where 100,000 died, that was a horrible accident. A US nuclear plant that typically generates in excess of 1,000MW releases 80mrems of radiation, and people consider that a horrible accident? Please!
On a side note, those consumption numbers are not projected. Those are Department of Energy figures from 2003. And yes, they include industry. I certainly hope you aren't pushing for a national energy policy that doesn't include at least gas stations. 3.848 trillion kilowatt-hours. That's the base target number. It only goes up from here.
Can we expect thin-film cells that are 10% efficient be produced for $40 per square metre within the next couple of decades? You're darned right we can.
Can we expect that fast neutron burner reactors can be produced using a smaller amount of area and for a cheaper cost than photovoltaics? You're darned right we can. 10 per state is all you'd need. Only five times more than what we already have, and we haven't built any new nuclear plants since the 70s. FYI: Nuclear accounts for 20% of all US electricity production and doesn't care if the wind doesn't blow nor if the sun shines as brightly.
Which brings up my final point. Even if solar could handle 90% of the load, that's not enough. 10% of the time being in the dark is not acceptable. Ever. Never was. Never will be,
First off, I am all for individual solar usage. Decentralization where possible is always a good thing.
That said, I think you need to stop drinking the Kool-Aid. Sure it's less land than what is used for farming. Guess what? Farming produces food. If some of those cell farms reduces the area available for farming, we produce less food. I don't know about you, but I like eating regularly and cheaply.
But I digress, go back to my previous post and find the math error. If my numbers are 10x what others have found, then my error should be easy to find. I actually believe that my numbers were too small since I didn't factor in the cost of batteries -- which add substantially to the cost and have much shorter lifespans than the solar panels themselves -- or the cost of labor -- someone needs to set them up, replace and maintain them and they'll want to get paid.
Oh yeah! And how about reducing our dependence on foreign oil? (...or oil in general.) What are the options? Biodiesel? That will take a substantial amount of arable land even if we go heavily in the direction of oil-producing algae. So what are our options? Reducing the amount of farmland for food crops? Not a good idea. What about algae off in the desert where no one's around? Oops! We have solar panels out there. Hydrogen? Sorry, that's not an energy source, it's an energy storage. How are you going to get the free hydrogen and compress/liquify it and transport it? That sounds like more energy. Wups! More solar panels!
I also did not factor in the reduced amount of ground available for other uses like say farming. Rooftops are not sufficient. Environmental concerns aren't eliminated either. Have you considered what 6,700 square miles of land blocked out from sunlight would do to the ecosystem? Be honest, have you even considered that?
But seriously, don't take someone's 1/10 cost analyses on faith. Do the math yourself. By all means, check my math. Find the mistake. If you do, let me know about it. If you can't, chances are someone has been sticking sunshine up your ass. I used to be a hardcore solar advocate until I actually did the math myself. It's just simple multiplication. You've got a brain. Use it!
Oh yeah, and by the way, thin-film (aka amorphous silicon) solar cells have a substantially shorter lifespan and are in fact only 5%-8% efficient today. Don't forget to factor that in as well.
If you want to know what the power requirements are for a real city, try factoring out the electricity needs of your average gas station. And don't forget that for people to put all of these solar panels on their rooftops, they actually have to be able to afford putting solar panels on their rooftops. Not to mention they have to actually be persuaded to do it. Inertia's a bitch, you know?
You cannot base an energy policy like the US's on solar power. It doesn't add up. Do the math. Don't take my word for it or anyone else's for that matter. Do the math yourself. It will work for a household. It won't work for a nation.
The average output per panel over an entire day is approximately 0.2kW per m^2. In other words, the sun provides direct light an average of six hours per day averaging 0.8kW per m^2 each of those six hours. I think that's a fair estimate.
Solar cells that are currently mass produced and have a reasonable lifetime (30 years or more) max out at about 15% efficiency. But I'll allow for incremental improvements if this was to roll out. Let's say 18% to be generous. 0.2kW/m^2 * 0.18 = 0.036kW/m^2.
Multiplying by 24 hours (since we already made an average based on the whole day) gives you 0.864kWh/m^2/day.
Multiply by 250 days (no place on the planet has 365 days of perfect sunshine, and yet I'm being generous) and you get 216kWh/year per sq. meter. Divide 3.848 trillion kWh by 216kWh per sq meter and you get 17,814,814,815 sq. meters. Divide by a million to get sq. kilometers. That comes to 17,815 square kilometers. Quick unit conversion leaves 6,878 square miles.
Now let's reflect. In this best case scenario where you have plenty of sunshine, better than the best mass produced cells available today, the cells are kept clean, no major earthquakes, no tornados, etc., you still need 6,878 square miles of the stuff. Last I looked, I see that a square meter panel costs about $500 -- and solar is federally subsidized! Even if you factor in economies of scale whereby subsidies are not necessary and street costs are slashed in half, you are talking about $4,453,703,703,704. Just so we're clear, that's $4.453 trillion dollars. Even if you reduced the price of panels by a factor of ten from what they are today, you are still talking about $800 billion. Also don't forget that this was a forgiving estimation.
More realistic estimates place the land necessary at 10,000 square kilometers and do no expect such huge drops in price. Remember, this would be a government contract. Nobody will be bidding particularly low.
And I haven't gotten to the best part yet. You have to replace a substantial amount of cells every thirty years or so as the cells wear out and are damaged (how do you protect thousands of square miles from acts of sabotage?). Oh yes, let's not forget that overall demand is increasing, not decreasing.
If this sounds reasonable to you, I think you have a problem with your brain not being screwed on tight.
...except they're not called dirty reactors. They're called fast neutron breeder/burner reactors.
And I wish people would stop mentioning outer space dumping. Why are we going to toss it? Because it's bad for our health and the environment, right? So how good for the environment do you think rockets are? All you need to do is look at a rocket's exhaust pipe to know how good an idea it is.
I know you were joking, but people actually think it's a good option. That needs to stop.
That would be 4.468 x 10^9 years of alpha decay. 4,468,000,000 years for the scientific notation-impaired.
And just so I can snip some morons off at the starting gate, a longer halflife entails a slower rate of decay which entails a lower ambient radioactivity which entails a lower threat.
Not everyone in Hollywood is a treehugger and NYC gets a substantial amount of its electricity from nuclear.
In 2003, U.S. nuclear power generation was 766 billion kWh, or about 20% of total U.S. electricity generation, second only to coal in the U.S. electricity generation mix. Nearly 40% of U.S. nuclear output was generated in just five states: Illinois, Pennsylvania, South Carolina, North Carolina, and New York. - Department of Energy Brief for 2003
Looks to me that three out of those five were blue states my friend. Perhaps the red states which are currently treehugger-deficient should get off their asses and build up some nuclear plants.
Republican-controlled House of Reps, Senate, Supreme Court and White House. Yeah, it's the treehuggers' fault.
Slashdot Mirror
SQLite is faster and supports atomicity. It slows down with multiple concurrent connections, but then so does MySQL. In the case of many simultaneous and concurrent connections, you want to look at PostgreSQL if a free database is on the menu.
Slony for PostgreSQL.
I stand corrected. Thank you.
And no one is trying to force them into caring what I think. I simply stated my opinion: it's a waste of time to reinvent an obsolete wheel. Take the advice or don't. That has no bearing on me airing my opinion.
1. The conversion from RCS to CVS is not necessarily seamless.
2. As Subversion whole reason for existence is to "fix CVS once and for all", there are migration tools to switch with.
The Apache Software Foundation has been steadily moving their revision control to Subversion and they have a *huge* amount of code. No one is suggesting you scrap everything you've got and starting over from scratch.
They take what amounts to a standard set of hacks on top of RCS. Then they make a port of it with a BSD license. Then... we're supposed to believe this is a good thing?
Subversion and arch would be better models wouldn't they? Hell, subversion has an Apache-style license to it. Closer to BSD than GNU CVS's GPL *and* Subversion is better than CVS right now.
I'm more than grateful to the OpenBSD project for their work on free firewall implementations, openssl, openssh, etc. But enough's enough. CVS? Aim a little fucking higher guys!
SVG!!!
They want their flood myth back. People say that prostitution is the oldest profession. This may be true, but plagiarism apparently wasn't far behind.
Apache takes >15 seconds to start? My god man, what are you running? My house server is a 1GHz Athlon and I basically don't see the startup -- I'm serving WebDAV pages (via Subversion and Apache2) from a cold start in less than a second. Even on a 486, it shouldn't take even close to 15 seconds just to start up. Reduce the MinStartServers settings for example.
Another note, are you running out of memory on the box? Unless you're using up >95% of available memory (and thus beginning to swap heavily), what does it matter?
As for RSS (and ps reports in general), don't believe everything you read. When Apache forks processes on a good OS, a copy-on-write occurs. This means that unless a particular page of memory actually changes, a child process allocates no additional RAM (simplification of course, but effectively true). In addition, older versions of ps and some OS kernels report threads as separate processes. I'm running Apache2 with the worker MPM on a Linux 2.4 system and it looks like a dozen processes taking the same amount of memory instead of one process with a set amount of memory.
And then of course there's the issue of memory allocation vs. memory usage. Many processes (not just Apache) have pages swapped out because they aren't actively used.
So after all that, are you sure that Apache is taking up as much memory as you believe? And are you hitting swap -- the real memory litmus test?
Sometimes I really hate comments like this. Just how heavy to you think Apache is? With PHP/Perl/Python/Kitchensink support loaded in, sure.
Try loading Apache with just the barest essentials of modules (core functionality in Apache 2). The resource footprint ain't very big. Also, in terms of speed, Apache 2 can use the sendfile(...) API, memory map resources, and mod_cache if you load in support for it. In this configuration, you can easily saturate a gigabit ethernet connection. So unless you've got a gigabit internet pipe, use of thttpd vs. Apache is a moot point.
And besides, if raw web file serving performance is your goal, your script algorithms, internal caching model and judicious use of reverse proxies will make far bigger differences than your choice of web server.
Now then, on to WebDAV. Your comment, "Are there any small, light tools that will just do WebDAV and nothing else, that I can add to my setup?" belies a fundamental ignorance of what WebDAV is. It's an HTTP layer for file handling. By definition, anything that "will just do WebDAV" will need to be a web server. Subversion has it's own transport, but prefers the use of Apache for access to its version control repository. Why? Because Apache handles HTTP well. Why reinvent the wheel?
So in summary, in order to use thttpd with WebDAV, you would need to use thttpd as a proxy to another web server that also handles WebDAV, or you can get someone to write extensions to thttpd so that the WebDAV HTTP extensions PUT, DELETE, MOVE, PROPFIND, LOCK/UNLOCK, etc. are implemented correctly. Of course you would just be rewriting Apache+mod_dav, but suit yourself.
For the record, I think a purely C or C++ desktop app on any OS is an absolutely horrible design decision from a security standpoint.
Regarding Sun's monetary woes, I don't know if they make enough money off of Java to cover their related costs. I imagine it does. It's their hardware and Solaris divisions that have performing so poorly lately. I know IBM does cover their Java-related investments easily. Being such a pragmatic company, I know that they didn't, they would have dropped it like a hot potato years ago.
They ain't using it for love of Sun, I can tell you that.
I'll try showing things from my point of view. I have been co-hosting a weekly science and technology radio talk show for the last four years. Right now we put the show archives on the web so people can listen at their leisure. But MP3s aren't so hot for dialog. To get voices to sound good, you have to up the bitrate which in turn ups the bandwidth usage.
So I researched around and found Ogg Speex. Even at low bitrates, speech sounds great. So at a smaller file size than MP3, I can get better quality for my listeners. Everybody wins, right?
Well, the codec has a problem. There isn't a uniformly good decoder for Windows, OS 9, OS X and various Unixes where I can just point someone to a URL and have them hear anything interesting -- unlike MP3. So what about a Java applet? There's a Speex decoder for the JavaMedia API. (An Ogg Theora as well, but I digress.) With even an older JVM on the system, codecs can be downloaded as needed. And after the user has left my website, no trace remains. Nothing to install and nothing to uninstall.
But...
There are quite a few people out there who refuse Java "on principle". My website is for a radio program. Audio is an intrinsic part of the overall equation. So what are the alternatives?
It's not that I think Java is perfect. It's that for many tasks, it's the best tool for the job.
As far as ActiveX goes, my hatred of it is a different animal than your hatred of Java. I cannot and will never trust ActiveX precisely because it's native code. You cannot build a code sandbox around a technology that allows direct pointer manipulation. Period. The use of ActiveX in all but the most rare intranets is absolutely unforgivable in my opinion from a network security perspective. Then of course we get into the fact that ActiveX only works on one browser on one operating system on one type of hardware -- quite the anathema to the original spirit of the internet. None of these items is true of Java. The worst indictment of Java is that it has been slow and people have used it for ad banners.
You hate Java for how it's been used. I hate ActiveX for what it is, its underlying design. There's a fundamental difference there.
Regarding NullPointerExceptions -- any unchecked exception for that matter -- and the end-user/developer divide, I couldn't disagree more. Developers get their bug reports from end-users. Stacktraces, being text, fall into log files easily. These log files get emailed to developers in "incident reports". Core files don't fall into log files quite so easily. Printable stacktraces with line number references was one of the best things to happen to the client-debug-patch loop in the software arena. Released binaries with debug symbols stripped out (as is common in shipped software) can be an absolute nightmare when trying to replicate in-house.
If it helps the developer fix bugs, it by definition helps the end-user and is therefore just as relevant to the end-user.
As far as ad banners go, the same technology used against Flash and Gif/Jpg ads could be applied to Java applets as well. The Ad Blocker extension to Firefox comes to mind. By default, all plugin or suspected ad banner activity is blocked from view unless you specifically enable it on a per-site basis. As far as if a complete site is based upon Flash or Java (a horrible design decision 99.9% of the time in my opinion), the simple answer is to avoid the site in the future.
I guess what I'm getting at is that there are technological solutions to these problems, but just turning it all off is akin to throwing the baby out with the bathwater.
You would guess wrong. I have coded for appservers, applets (where I started with Java), and standalone applications. AWT since the 1.02/1.1 transition and Swing since the 0.5 beta.
Yes, there are differences in rendering on different platforms -- mainly the sizes and shapes of native widget peers. I have also had FAR more problems getting GTK+ to work on X and Windows. It's like nitpicking that HTML isn't crossplatform because h1 tags use a different default font and sizing depending on the browser/platform. HTML addressed it (mostly) with CSS. Java addressed it (mostly) with the metal UI. They are issues, but far and away less of a problem than alternatives. Are you honestly going to try to tell me that Java is inferior to millions of #ifdef statements? Please.
Oracle installers aside -- and that argument holds little water with me since Oracle had crap JDBC drivers for years too (evidence of bad programming, not a bad programming environment) -- I have had very few inherent Java problems. The web plugin has been extremely stable in my experience. Server apps have been as stable or more so than many of their C or C++ counterparts. I can't remember the last time I heard of a Java app allowing a remote exploit by way of buffer overflow.
As for the statements "Perl works" et al., you haven't left the traditional UNIX world lately have you? Go to Windows and you'll find out how many vaunted CPAN modules were written for UNIX only. Go to OS X and tell me how easy it is to install the Python Imaging Library, a very common dependency for many apps. Done much debugging of C++ where templates (including the STL) are used extensively? Nothing "just works". Chances are the things that "just work" do so because the environment was set up for you already in the distribution. Yes, this is largely because the JDK/JRE aren't allowed to be redistributed with the operating system in most cases. Yes, this is the biggest reason why Java should get a more liberal license. But there is nothing inherent to the VM setup or libraries that makes it inferior to the others.
java -jar myapp.jar
Works for me. If a standalone app can't be started reliably like this, blame the program author, not Java. The Java plugins come with the JRE. Make a symbolic link to the browser's plugin directory. Done. All users on my multiuser server have the plugin installed. Run the JRE installer on Windows. Done. All users on the XP box have the plugin installed. I don't why it's been so hard for you when it's been so much easier for me.
This isn't even like when your kids are out on their own. They're in the house. There are no hard and fast rules for how long is too long, but if you think the line is being crossed, walk over to the computer, reach behind the back of the case and pull the power cable.
If your teenager is spending too much time on the telephone, pull the cord out of the wall.
That said, make sure you know what your kids are doing online. No, I don't mean spying. I mean are they IMing their friends, IMing some letcher or learning how to program? Are they "wasting time" on howstuffworks.com or incessantly playing Doom3?
And make sure that you periodically kick them out of the house to play soccer.
Exactly! And another aspect that people can't seem to wrap their heads around is the lack of confirmation windows in Java client-side. Sure a signed applet that will be accessing the local filesystem or connecting to an arbitrary server on the net will pop up a dialog box as it should, but normally it just starts up and runs.
ActiveX pops up a dialog box at every new instance on every site. The user ends up thinking, "Oh, another damned popup," and just clicks on it. It's like email and dealing with spam. There are so many junk emails, eventually you make a mistake accepting one you shouldn't have or dumping one that you would have wanted.
With the Java applet sandbox, only actions that are potentially dangerous require a confirmation dialog, and 99.9% of all applets do not need signing. Sure, today Sun announced a vulnerability. That makes how many in the last ten years? Seriously, compare that number with the number of exploits in basically any network-aware program in any language. Dumping Java over this is like refusing to go out to restaurants anymore because a friend of a friend got food poisoning.
You want to be absolutely safe, unplug your network or modem cable. There you go. Absolute network safety. Life is a compromise.
Problems with CLASSPATH? Right. Like people don't have many of the same problems with PATH and LD_LIBRARY_PATH. Your problems are inherent in splitting programs into modular pieces, not with Java specifically.
As for a multiuser system and Java, I've been doing it for years. Wasn't all that bad. You have a wrapper script in
So you have plugins including Java applets turned off but then say you haven't seen any useful applets. So let me get this straight: you hide them and then complain that you can't see any good ones. Self-fulfilling prophecy? By that metric, do you drop all usage of OS X if you come across a badly written program on the Mac? Starting the plugin the first time is slow, granted. But I've been running Safari on a 500MHz iBook and Java applets haven't been a problem for me. The best written ones have been the ones where I almost didn't notice they were applets. Well-written ones are like this. A lot of folks who denigrate Java out of hand have come across good applets but not recognized them as Java.
Have you used Java since the old Netscape days? The plugins in IE, Mozilla, Firefox and Safari have not caused me any problems in years. I find it hard to believe that I've just been the only person in the world and/or am extremely lucky.
Well... except for that one applet that was a site logo rippling like it was underwater. Pure eye candy that sucked up 60% CPU time sustained on a 3GHz processor. Once again, good technology, bad applet writer.
That said, I prefer DHTML and related technologies to visual Java applets these days. In a better world, I would have the UI handled by the browser's renderer and the logic handled by Java. Javascript is nice and all, but sometimes you want to do some heavier lifting. And I sure as hell am not going to use ActiveX for that even if it was supported on non-IE and non-Windows environments.
And I too am talking from experience as I have developed on Java on Windows since Win95, OS/2 Warp, Novell NetWare, Solaris, OS X and Linux. Applets, servlets, EJBs and standalone apps. Aside from filesystem path differences, I have had maybe two problems in the last seven years moving my code from one platform to the next. And yes, I can code in C (K&R and ANSI) and C++ (including ISO98) too. Learned them before Java, so it's not because I haven't seen any other platforms.
By the way, your mention of NullPointerException is funny to me. Take a C app and access a null pointer. Boom! Hope you have core files enabled so you load the image in a handy debugger. Take a Java app and access a null reference (pointer). Not only can the exception be caught so that it doesn't completely take down the app, but you get an easy to read (relative to C and C++) stacktrace telling you exactly where it occurred so that you can fix it.
It's not the only language in the world and definitely isn't the only language you should have in your toolbelt, but it doesn't deserve the maligning you just gave it.
Deaths: zero
Injuries: zero
Exposure to radiation: none
Effect on environment: nothing
Yeah, sounds like a catastrophe. Read all about the accident here. It's really fascinating. They look at what happened. They found out why it happened. They designed a new part to make sure it never happens again. The safety analysis and manufacture of this new part is a major reason why the plant has remained offline for so long. Yeah, those nuclear engineers are reckless. (sarcasm)
Yes, I'll grant you sodium requires special handling. You know what? So does sulphuric acid. So does gunpowder. So does phosgene, monomethylamine, methylisocyanate and the pesticide carbaryl. You want to eliminate the handling of toxic, carcinigenic, flammable and explosive substances? Get used to a lifestyle similar to a Bangladeshi sheep herder. See those papers on your desk? These required the tons of chlorine sitting in train cars outside the paper factory.
Sodium is just one of many potentially bad things that can be used to enhance our lives. So what happens if the sodium leaks? Well, the sodium helps neutron flux in a fast reactor. You take away the sodium, the core will likely go subcritical (shut down). If not, the fuel might partially melt. Still won't cause a problem. Then maybe there is some malice or gross negligence and someone allows a rush of oxygen and/or water into the core igniting the sodium and causing an explosion. Still won't crack the protective dome on all modern nuclear reactors. So even in the event of a catastrophic series of highly unlikely situations, you're still not likely going to affect anyone except the energy company's pocketbooks (and the customer as the costs get passed down). So it's in their best interests to play it safe and put in safeguards to substantially reduce the risks.
Contrary to popular belief, nuclear plant design didn't stop in the 70s. Today's new designs don't rely on trained operators, computer controls, pumps, or valves. They are designed so that if anything goes wrong, the natural state is to shut down. This means relying on things like heat convection, thermodynamics, electromagnetism, and my personal favorite, gravity.
Think about this:
Q. What was the worst nuclear accident in US history?
A. Three Mile Island
Deaths: zero
Injuries: zero
Effect on environment: nothing
Exposure to radiation: ~80mrems (normal background radiation is 250mrems)
And yet if you ask people about TMI, they will say this was considered a horrible accident. The chemical plant accident in Bhopal, India where 100,000 died, that was a horrible accident. A US nuclear plant that typically generates in excess of 1,000MW releases 80mrems of radiation, and people consider that a horrible accident? Please!
Several thousand square miles of the stuff.
And what do you do during the rainy months? (The northern states have a lot of those.)
Can we expect that fast neutron burner reactors can be produced using a smaller amount of area and for a cheaper cost than photovoltaics? You're darned right we can. 10 per state is all you'd need. Only five times more than what we already have, and we haven't built any new nuclear plants since the 70s. FYI: Nuclear accounts for 20% of all US electricity production and doesn't care if the wind doesn't blow nor if the sun shines as brightly.
Which brings up my final point. Even if solar could handle 90% of the load, that's not enough. 10% of the time being in the dark is not acceptable. Ever. Never was. Never will be,
First off, I am all for individual solar usage. Decentralization where possible is always a good thing.
That said, I think you need to stop drinking the Kool-Aid. Sure it's less land than what is used for farming. Guess what? Farming produces food. If some of those cell farms reduces the area available for farming, we produce less food. I don't know about you, but I like eating regularly and cheaply.
But I digress, go back to my previous post and find the math error. If my numbers are 10x what others have found, then my error should be easy to find. I actually believe that my numbers were too small since I didn't factor in the cost of batteries -- which add substantially to the cost and have much shorter lifespans than the solar panels themselves -- or the cost of labor -- someone needs to set them up, replace and maintain them and they'll want to get paid.
Oh yeah! And how about reducing our dependence on foreign oil? (...or oil in general.) What are the options? Biodiesel? That will take a substantial amount of arable land even if we go heavily in the direction of oil-producing algae. So what are our options? Reducing the amount of farmland for food crops? Not a good idea. What about algae off in the desert where no one's around? Oops! We have solar panels out there. Hydrogen? Sorry, that's not an energy source, it's an energy storage. How are you going to get the free hydrogen and compress/liquify it and transport it? That sounds like more energy. Wups! More solar panels!
I also did not factor in the reduced amount of ground available for other uses like say farming. Rooftops are not sufficient. Environmental concerns aren't eliminated either. Have you considered what 6,700 square miles of land blocked out from sunlight would do to the ecosystem? Be honest, have you even considered that?
But seriously, don't take someone's 1/10 cost analyses on faith. Do the math yourself. By all means, check my math. Find the mistake. If you do, let me know about it. If you can't, chances are someone has been sticking sunshine up your ass. I used to be a hardcore solar advocate until I actually did the math myself. It's just simple multiplication. You've got a brain. Use it!
Oh yeah, and by the way, thin-film (aka amorphous silicon) solar cells have a substantially shorter lifespan and are in fact only 5%-8% efficient today. Don't forget to factor that in as well.
If you want to know what the power requirements are for a real city, try factoring out the electricity needs of your average gas station. And don't forget that for people to put all of these solar panels on their rooftops, they actually have to be able to afford putting solar panels on their rooftops. Not to mention they have to actually be persuaded to do it. Inertia's a bitch, you know?
You cannot base an energy policy like the US's on solar power. It doesn't add up. Do the math. Don't take my word for it or anyone else's for that matter. Do the math yourself. It will work for a household. It won't work for a nation.
Let's do the math together.
First, we take the solar constant, 1.367kW/m^2.
The average output per panel over an entire day is approximately 0.2kW per m^2. In other words, the sun provides direct light an average of six hours per day averaging 0.8kW per m^2 each of those six hours. I think that's a fair estimate.
Solar cells that are currently mass produced and have a reasonable lifetime (30 years or more) max out at about 15% efficiency. But I'll allow for incremental improvements if this was to roll out. Let's say 18% to be generous. 0.2kW/m^2 * 0.18 = 0.036kW/m^2.
Multiplying by 24 hours (since we already made an average based on the whole day) gives you 0.864kWh/m^2/day.
Multiply by 250 days (no place on the planet has 365 days of perfect sunshine, and yet I'm being generous) and you get 216kWh/year per sq. meter. Divide 3.848 trillion kWh by 216kWh per sq meter and you get 17,814,814,815 sq. meters. Divide by a million to get sq. kilometers. That comes to 17,815 square kilometers. Quick unit conversion leaves 6,878 square miles.
Now let's reflect. In this best case scenario where you have plenty of sunshine, better than the best mass produced cells available today, the cells are kept clean, no major earthquakes, no tornados, etc., you still need 6,878 square miles of the stuff. Last I looked, I see that a square meter panel costs about $500 -- and solar is federally subsidized! Even if you factor in economies of scale whereby subsidies are not necessary and street costs are slashed in half, you are talking about $4,453,703,703,704. Just so we're clear, that's $4.453 trillion dollars. Even if you reduced the price of panels by a factor of ten from what they are today, you are still talking about $800 billion. Also don't forget that this was a forgiving estimation.
More realistic estimates place the land necessary at 10,000 square kilometers and do no expect such huge drops in price. Remember, this would be a government contract. Nobody will be bidding particularly low.
And I haven't gotten to the best part yet. You have to replace a substantial amount of cells every thirty years or so as the cells wear out and are damaged (how do you protect thousands of square miles from acts of sabotage?). Oh yes, let's not forget that overall demand is increasing, not decreasing.
If this sounds reasonable to you, I think you have a problem with your brain not being screwed on tight.
...except they're not called dirty reactors. They're called fast neutron breeder/burner reactors.
And I wish people would stop mentioning outer space dumping. Why are we going to toss it? Because it's bad for our health and the environment, right? So how good for the environment do you think rockets are? All you need to do is look at a rocket's exhaust pipe to know how good an idea it is.
I know you were joking, but people actually think it's a good option. That needs to stop.
And just so I can snip some morons off at the starting gate, a longer halflife entails a slower rate of decay which entails a lower ambient radioactivity which entails a lower threat.
Looks to me that three out of those five were blue states my friend. Perhaps the red states which are currently treehugger-deficient should get off their asses and build up some nuclear plants.
Republican-controlled House of Reps, Senate, Supreme Court and White House. Yeah, it's the treehuggers' fault.