It's a big hack at the moment... we have an override system that runs on top of FreeBSD ports to try to keep the more interesting ports operational.
The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.
Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.
Ok, I'm an old-timer now I guess. My current roadbike is the one I bought in highschool in the 80's. I recently decided I needed a new derailer so I brought it in to a shop.
Of course, with a bike that old, they would have had to replace, well, just about everything in order to put in a new derailer. In fact it would be only slightly more to simply buy a new bycycle!
So I started looking at bikes. I could get a nice road bike for $800 (US) that was far superior to my existing bike. Then I started looking at the carbon composite bikes, like the Roubaix series. I really didn't think I'd feel the difference until I test-rode one.
Holy S*it! If the $800 bike was an order of magnitude better then my existing one, the Roubaix Comp (at $2600) was an order of magnitude better then the $800 bike. All carbon-composite construction, vibration dampening... the works. Unbelievably light, I could lift the whole bike with my pinky pretty much! Smooth ride, ultra smooth shifting, huge gearing range. The technology is really amazing.
Even data committed to disk can be lost, the reason being that most modern IDE drives these days do whole-track writes. SCSI drives are often billed as being more robust but low error rates and economic pressures no longer make that a slam dunk. So if you modify sector A and your hard drive crashes you can lose sector's B-Z even though you didn't actually write to them.
To be really safe you need to journal to a totally different physical device then the one holding the filesystem, even possibly one on an entirely different machine or in an entirely different machine room or, if you are really paranoid, one that is located off-site.
Another advantage of a full off-machine data+meta journal is that you can reconstruct a filesystem which has been corrupted due to OS or hardware glitches.
good tips except for #4, which I would disagree with quite strongly. Built-in flashes usually produce horrible results but a mounted flash bounced off the ceiling produces quite excellent results (and if you can't do that, a using a diffusor is your next best option). While it takes time to learn, controlling the flash exposure can produce really excellent results. You definitely do not want to bump up the ASA setting, at least not too much, because that will result in horrible digital noise and greatly reduce your post-processing options. The important thing to remember when using a flash on a digital camera is simply to avoid washing out the detail in the picture and not blowing up the white balance too badly (bounce and diffusor make a huge difference in how the results look). Most anything else can be fixed in gimp or photoshop. (e.g. the balloonman url I posted earlier is an example of an unedited photo which contains sufficient contrast, low noise, and detail to be very easily editable in gimp or photoshop for production output).
Even a point-and-shoot's flash will produce reasonable shadow fill results for daylight photos. Try this experiement: In bright sunlight take a picture of a friend's face where part of his face is significantly shadowed (e.g. by his hair or the angle of the sun). Take the picture with and without the flash, then load both into gimp or photoshop and see how well you can clean them up. You will find that you can clean up the fill-flashed picture a lot more easily.
Example #2: open your garage door and from inside the garage take a photo that includes portions of the inside (in shadow) and outside (in the sun) of the garage. Do this with and without fill flash and bring them into gimp/photoshop. You will find the fill flash photo a lot easier to clean up.
Heh, I could fill a book getting every detail down. The presumption is that you pretty much have to have the flash at at least 45 degrees with a diffusor, otherwise the focusing element on the flash won't necessarily go wide-angle. So, yes, definitely angle the flash with a diffusor.
It took me a while to learn how to use the 420EX, but it's really easy once you've played with one for a while. I started out locking the exposure at 1/200 but once I realized that automatic flash compensation actually worked properly in Manual mode I pretty much just use Manual mode (with the 10D, I don't think it works with the 300D) for late afternoon/evening/night flash shots, and Av for daylight shadow fill flash shots. (You have to use something that controls the aperture when using this particular Sigma lens because it has very bad distortion at low F-stops... but it's an excellent lens at F4). I wish the wireless 5xx series didn't cost so much (you need an additional expensive piece of equipment to actually use it in wireless mode), else I'd have someone hand-holding a second flash to get better coverage.
Flash brackets are just too imposing, I hardly ever use mine any more (the 10D with the flash and Sigma 20mm lens alone is already almost too imposing for casual shots).
And, as for the silly anonymous posters denegrating my wonderful balloonman shots:-), well, they can kiss my ass for all I care, and put up some URLs with their full blown non-thumbnailed shots if they care to compare casual pics. I didn't edit any of those photos and there's plenty of contrast there to work with. The glossy prints look very good (though the flower shots are of course much better since I didn't have to deal with a near pitch black warehouse), and most of those were taken wide frame for crop-down purposes anyway. But, of course, those anonymous bozos don't understand any of that so I don't even know why I bother trying to explain it to them.
I have a funny story about my attempt to take a picture with my old G2 of my buddy snowboarding down the hill towards me.
So here, he comes... looking good, I hold down the shutter button hoping to get a few shots off. I've taken into account the ~1 second lag.
But there is no click. Here he comes, heading right towards me... no click. no click. no click... he's past me. I drop my arm down in disgust (still holding my finger down on the shutter release), not one shot was taken!
Then I hear a click (the camera just took a shot of my feet!), and realize what happened. The camera had been unable to autofocus on the target moving towards me. It kept trying, and kept failing.
Of course the G2 is quite old by now. But it's still a funny story.
This isn't true at all. Lens for a digital SLR (such as a Canon) are in fact the same lens one uses for their film SLRs. They aren't going to magically cost loss just because you have a film body. Same lens, same flash, same cost. Different body, different cost... but just for the body.
So the only difference in cost is the body and storage, and while it is true that a digital body costs more then a film body, it isn't on the order of 'thousands of dollars'. More like around a thousand dollar difference, tops for a good prosumer digital SLR. High-end digital SLRs such as the Canon 1Ds are certainly far more expensive, but their prices have been coming down steadily. All the professional photographers I know have switched to digital (though many keep a film camera around for traditional black and white shots), and for good reason: they can produce pictures that are just as good for most particular purposes, and it takes far less time to prepare the shots for printing then it does for film and that time factor alone more then makes up for the difference in cost, even for a high-end SLR.
Film is dead. Actually, film died a while ago, it's just taking awhile for the old farts to realize it.
Here are some more examples of flash shots. My parent's maintain a wonderful garden and they were on the Secret Garden Tour in Berkeley this year. I took a lot of shots of flowers. Unlike the NextFest shots, which were in a dark warehouse, nearly all of the garden shots were in bright sunlight. Proper use of the flash filled in the shadows and narrowed the contrast range, producing some incredible flower shots.
I should have saved some of the test shots I took with and without the flash but I didn't. Suffice it to say that most of these shots would not look anywhere near as good as they look without the flash to provide shadow fill.
If you want the perfect shot, proper use of a flash is essential, especially with the limited contrast range (not enough bits per pixel) that even good digital cameras have issues with.
(1) Get a good bounce flash, e.g. like the Canon 420 EX for Canon EOS cameras.
(2) Get a diffusor ($0.01 worth of milky plastic, usually $5-$10 retail). For most shots either bounce the flash off the ceiling or use the diffusor. Never use a direct-pointing flash unless you have no choice (e.g. shots from a distance).
(3) Learn how to properly use Tv, Av, and Manual modes with the flash to properly fill the image. I generally either use Av with the flash sync fixed at 1/200, or Manual mode to control how much of the shot is from natural light and how much is from the flash (on the Canon the flash exposure is automatic when operating in manual mode though for obvious reasons you have to be more careful about its exposure range capabilities).
(4) The proper use of a flash for fill is even more important in bright sunlight due to the huge contrast between shadow and sunlight (especially on faces). I almost universally use the flash with the diffusor for daylight shots.
And that's pretty much it. Most people don't use flashes properly, but it doesn't take much exposure:-) to at least double and maybe even triple the number of good shots you take in a day. As usual, I just happen to have some great examples:
This is all well and nice but I've heard it all before. There's no point if the resulting panels do not have at least a 30-year lifespan before they degrade beyond useability. The sun does a pretty damn good job destroying things.
I voted using one of those machines in the last election. I've never seen a worse, design, rittled with security issues and no verification mechanisms at all. Thank god they've been banned!
There was no receipt, no way to determine after the fact whether my vote actually made it out of the polling place, or even if it was properly recorded. The machines should never have been allowed to be used in the first place.
All of these pictures were taken with my Canon-EOS10D, 420EX flash (used mainly for shadow fill), and Sigma 20mm 1:1.8 EX DG prime lens. The shots were taken hand-held in AP mode using F4.0-F16 depending on the conditions. This particular lens produces ultra sharp results at F4.0-F13 or so. The 10D (and 300D) use a 6 MPix low-noise CMOS sensor and you can see it in the above shots.
Insofar as all the discussion goes, from my point of view it all comes down to three things: Lens Quality, Sensor Quality, and Dynamic Range (of the exposure). SLR's like the 10D have gotten good enough that I don't use film any more. The lens quality is there (being an SLR and taking the same lens as the film EOS's), sensor quality is there, and while dynamic range still needs another 2-4 bits of resolution for my comfort it's still good enough for 99% of the shots I take. Film is dead, digital rendition at 11!
And I tend to agree with the few other obviously experienced comments (verses the bozo comments from people that don't know jack about taking photographs). You first need to know how to take a picture before you can take a good one. Then comes lens and sensor noise. A lens hood is important, and a good flash (articulated for bounce shots and also be sure to have a diffusor handy) is very important (even when you don't think you need it). For example, most of those flower shots I took were with flash+diffusor, even though it was a bright sunny day outside. The flash was used primarily to fill in some of the shadow (one way to correct for limited dynamic range but it also makes the shots look a lot better).
GigE is now sitting at a lower price point then when 100BaseT began to take over from 10BaseT. The fanless Netgear GS108 8-port copper GigE (unmanaged) switch sells for $157 or less now and its night and day better then older switches like the GS504T (which was bulky, had a very noisy fan, and is now collecting dust on a shelf). Intel Pro/1000MT cards are wildly popular and work with all major operating systems, including Linux and *BSD, and cost around $35.
My advise: don't bother trying to find equipment that can handle Jumbo frames. Most unmanaged GigE switches don't, and equivalent managed switches (many of which do handle Jumbos) are priced at a premium over their unmanaged brethren. You should only buy a managed switch if you actually need a managed switch. It takes a lot of effort to configure a network to use Jumbo frames for certain links and not for other links, and it just isn't worth it 99.9% of the time. If you want performance, focus on smart GigE cards that offload a good chunk of the packet processing (e.g. like checksum calculations and fragment reassembly). The Intel cards are a good start.
As to whether your network needs GigE or not... well, it depends on what you are using your network for. I use NFS all over my network and with GigE I get virtually the same disk performance over the network that I get with local disk. I also run backups over the LAN and the backups that run over GiGE go a lot faster then the ones that run over 100BaseT. Even more to the point, I've started distributing video over the network and 100BaseT just doesn't cut it for more then two or three streams.
If you are going to buy a new switch, you might as well get a GigE switch.
This is old news. The letters sent to the two agencies were simply SCO's standard threatening letter which they sent in December 2003. They're just pulling it out now to create more FUD. Nothing new has happened.
Air Conditioners eat a lot of power, about a kilowatt per 700sqft. If you have a 2100sqft home airconditioning will eat around 3kW while operating. A 2.5kW solar system is considered fairly large by home standards (I have a 2.5KW system which you can see at: My Solar Panel System). This system produces about 16KwH/day in the summer and the 2.5kW is only generated for two or three hours at the peak of the day for a few weeks at high summer... nowhere near enough to run even a moderately sized AC unit. My system is setup as two strings of 9 panels fed into a high voltage inverter which then connects to the house side of the meter (and thus the grid). This is the most typical type of system found today. Older LV (low voltage) systems have higher wire and inverter conversion losses. HV systems are very efficient converting the DC into AC and have no significant wiring losses.
In terms of batteries... you only ever use batteries if you are off-grid or if the grid is really unreliable. If you are tied to the grid you do not usually use batteries... the Solar system goes through an inverter and powers the house, and any excess is fed back to the grid (running your meter backwards). The grid acts as the 'battery' in this case. If you are not producing enough to power your house, the remainder is fed to you from the grid. Grid-tie systems without batteries are the *simplest* and *cheapest* type of PV system you can buy, but you are still talking about $15-$20K for the system you see above. Systems with batteries cost a lot more (add another $5-$10K at least) plus you have maintainance requirements (Batteries wear out), and you need an ATS (Automatic Transfer Switch) which itself is expensive. On the otherhand, systems without batteries are nearly 100% maintinance free. Without batteries means that if the grid goes down, you go down too. Most people live in areas where the grid is reliable enough that there's no point doing battery storage. Also keep in mind that battery systems have much higher losses then grid-tie systems because you have a loss charging the battery and another one pulling energy out of the battery on top of the inverter losses.
Typical home AC systems eat 3kW while larger home systems eat 5kW (for homes, not apartments).
Lets say you had an AC unit that eats 3kW while operating. A 2.5KW grid-tie system producing 16KwH/day would be able to run such a unit for 5 hours. As you can see, the PV system itself would not be able to power the AC unit alone, it would definitely need help from the grid, but if you only ran the AC for 5 hours the PV system would run your meter backwards the rest of the time and make up for it.
Five hours is not usually enough running time to really be able to cool a house unless you live in dessert conditions where it gets cold at night, in which case you really need to cool the house down at night so it stays cool enough so you don't have to turn on the AC until the afternoon (12-5p.m.)
So, generally speaking, trying to run an AC system with a PV (solar power) system is a bad investment. You could try running a smaller AC system but the sun generates something like a kilowatt of heat per square meter and it will easily overpower a small AC system if you do not have good insulation. Note, in particular, that if you do not have good wall insulation the sun is likely to overpower your AC during the afternoon when the sun is hitting the side of the house instead of the roof.
You would be far wiser to invest in passive technologies such as improved insulation and infra-red reflective shading. If water is cheap (or even if it isn't), a swamp cooler (rooftop evaporator) is often a great investment... it's cheap and it provides some cooling at a far lower cost then AC in electricity use. I've heard people mention GeoThermal, and it does work, but if GeoThermal is not put in when the house is actually built it can't take advantage of an under-the-house installation. Getting enough suds out o
It's an advantage in concept. The serializing token abstraction is a far easier model to program to because the semantics are totally different then mutexes. For example, when you obtain multiple mutexes you have to be very careful about lock ordering issues, and when you have one major subsystem holding a mutex call another major subsystem that might block, you have to (in FreeBSD-5) make the second subsystem aware of the first subsystem's mutexes, creating major code pollution all over the place.
The serializing tokens used by DragonFly work differently. They only guarentee serialization while the thread holding the token is actually running. Other threads holding the same token will be allowed to run when the first thread blocks or switches away synchronously, and the original thread will not get the cpu back until the tokens it is holding are available again.
This means that threads can obtain tokens in any order they wish, and that threads can hold tokens across blocking situations or calls to other subsystems without having to tell those subsystems about it. It may seem like a small thing, but the result is a huge simplification of the programming model. The tokens act almost like mini-BGL's (Big Giant Locks) but have the added advantage of protecting against interrupt threads trying to hold the same token. We are planning to expand the token idea further into a shared/exclusive model. The shared/exclusive model would have characteristics very similar to RCU.
The actual internal implementation of our token code is also quite a bit more flexible, allowing us to rip the guts out and rework it as needed for performance without changing the abstraction.
I don't think it's anyone's design in particular, but I tend to sit down and write things from scratch rather then copy other people's ideas. In the case of the thread replication used by the network stack, it is primarily Jeffrey Hsu's work and since he is big on reading papers I'm sure it's a combination of his own design and ideas gleaned from various published papers.
No, the critical section code simply increments and decrements a per-cpu variable. No locking is required at all... critical sections are local to the cpu, not global to the system.
In regards to cache issues, lets say you have a quad opteron system. Each cpu has a 1MB L2 cache. If you migrate threads willy nilly you basically wind up in a situation where each of the four cpu's L2 caches contain the same data. In effect, you wind up with a system that globally has only a tad more then 1MB of L2 cache. If you partition data (such as TCP protocol data) across distinct threads, and place those threads on different cpus, then you are in effect partioning your system's memory across all four cpu caches and you wind up with a system that globally has 3-4MB of L2 cache instead of 1-2MB.
There are two costs being saved here. (1) the cost of having to go to main memory when a piece of data is not in the L1/L2 cache, which can run into the hundreds of cpu cycles, and (2) the cost of cache mastership changes for all the data associated with the thread that was migrated (repeated each time the thread migrates).
The system core is lockless... there are no mutexes. For example, the LWKT scheduler core operates entirely without mutexes. Only critical sections are used to protect against local interrupts. A critical section is per-cpu, and really only needs to increment and decrement a per-cpu variable. As such the crit_enter()/crit_exit() code does not need to use any locked bus-cycle instructions or anything fancy at all, really.
The LWKT scheduler on any given cpu is only allowed to operate on threads owned by that cpu. If you attempt to wakeup a thread owned by a different cpu, an asynchronous IPI message is sent to the target cpu's LWKT subsystem requesting that the specified thread be woken up. It's really that simple. Same goes for cross-cpu scheduling.
IPI messages themselves are lockless and require no mutexes to operate because the cpucpu messaging uses a software crossbar (array of FIFOs) approach.
Not exactly. All this means is that threads do not migrate preemptively, nor do they migrate while blocked or switched out while in kernel mode. Threads only migrate if (a) the thread itself wants to move to another cpu or (b) the thread is returning to user mode and the userland scheduler decides to migrate the thread to balance the load out (which only applies to threads associated with user processes since no other type of thread can 'return to usermode').
Kernel threads almost universally stay on the cpu they were originally assigned to. High performance threaded subsystems, such as the network stack, are replicated. That is, the network stack creates multiple threads (one per cpu) and those threads do not migrate because, obviously, they do not need to.
Generally speaking, the purpose of making thread migration explicit instead of automatic is to partition a larger data set across available cpu caches rather then cause the same data to be shared amoungst all cpu caches. The processors operate a lot more efficiently and SMP scales a lot better. Most people do not realize the horrendous cost of moving threads between cpus because the cache mastership change is invisibly handled by hardware, but the cost is still there and still very real.
AMD has come a long way from the days of ratty clones. Intel really screwed itself trying to push raw clock speed. AMD stuck to their guns and made a marketing push to put a stop to the idiotic raw frequency comparisons... and they won. Intel overextended their cpu pipeline and their chips burn a lot more power for the same performance. And for blade servers, power and heat are far more important then who is able to eek-out the extra 5% in performance.
A lot of consumers want 64 bit computing and 32 bit compatibility. I want it... I have several Athlon64 boxes already. Gamers very definitely want it. Intel has been able to maintain an edge primarily through fab (chip feature reduction) tricks. AMD actually has the better design and they have had it for over a year.
If you don't believe me then perhaps you are unaware of the advances that have made to the insides of cpus in recent years. AMD more then holds its own. Here is a URL ref describing the Opteron's internal logic.
The problem the film world faces isn't that Digital is hands-down better then film in all cases, but that digital is hands-down better then film in 95% of the situations where film is used. This leaves film with less then 5% of its current market, and spells doom for film as a 'volume' industry.
Even medium format is taking a beating. Something like the EOS-10D (which I have) may not quite have the color depth or contrast to beat medium format, but the Canon sensor has virtually no noise and plenty sufficient resolution to take probably 70%+ of medium format's market share, and the convenience is two-orders of magnitude greater then anything you will ever get with any sort of film-based system. Hell, it's even more convenient to take multiple shots and stitch them together for poster-sized HR output then it is to use a medium format camera. I take thousands of shots now where I used to only take hundreds with my film SLR.
The new generation of photoprinters, like the i960, is probably an even worse indicator for Kodak. While it is still less expensive to send your digital photos off to a professional shop for printing the fact of the matter is that high quality consumer printing technology is now widely available and that spells doom for traditional companies like Kodak which depend on marketshare and volume to make their money. Photoprinting is now a market that cannot be 'cornered'.
In anycase, I wrote up a review of my 10D which is available:
What a stupid article. I've been in this scene for 25 years and the author falls into the same trap that most computer illiterates (which I define as: anyone who has never written a program) fall into. Just because something is sold under a corporate umbrella does not magically make it more secure or more robust or even better reviewed. In my experience, in fact, the exact opposite is true. If the author thinks that open source is more of a security risk then god help him for all the commercial software he trusts, for it is no better!
Right. buildworld, buildkernel, installkernel, installworld. DFly maintains pretty good compatibility with FBsd-4.x binaries (but not 5.x! It's dynamic root will blow up on you if you try this from 5.x!).
Once world is installed do a 'make upgrade' to unconditionally copy files that sysops are not supposed to modify, like/etc/rc* and/etc/rc.d/*. Do this before doing the mergemaster, it will make the remaining merge a lot easier and also get rid of a ton of 4.x junk files that are either no longer used or have been moved in DFly. Hmm, you might have to wipe (rm -rf ) your/usr/include
and 'make includes' to generate a new set to get rid of old 4.x junk files in the include dir too. You will want to install new boot blocks as well, though this is not required. DFly has backported 5.x's new boot loader which is a whole lot better then 4.x's, and you get some spiffy ascii art too.
Really the best thing to do is to download and burn the DragonFly Live CD ISO, boot your machine from the CD, and follow the README file to completely wipe and reload your box with DFly. Obviously make a backup of your old system first:-). If you just want to play with DFly without messing up your HD, you can boot the CD and play around a little from there (keeping in mind that/tmp and/var and/etc are MFS volumes). The CD boots into a fully operational environment.
Which, very soon now, will hopefully bite SCO in the ass. It's hard to justify significant damages (or any damages at all) for a measily 200 lines of potentially 'stolen' code (SysV->Linux) when all 200 lines have either already been put in the public domain or are obsolete versions of things which ALREADY have equivalent or better functionality in the BSD codepath (the key being that the BSD codepath is completely protected from SCO's foolishness due to the USL lawsuit that AT&T lost).
I've seen companies go down this road before. In many respects it is a holdover from the pre-internet days (or the pre-widely-dissemenated-internet days), where companies could obfuscate facts and possibly succeed in their absurdities simply due to a lack of collaboration and coordination by their opponents. But in the age of the internet, the truth becomes viral and companies like SCO and VeriSign have a much harder time playing the system.
This isn't to say that the Media has clued in yet. Up until recently SCO got only glowing reports from investment media sources and research, primarily because most media and research sources simply parrot official press releases from the company and the open-source community has no 'official' source. But even the total idiots writing the glowing press articles are finally clueing into SCO's criminality. Not enough of them, yet, but the tide is turning.
Slashdot Mirror
The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.
Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.
-Matt
Of course, with a bike that old, they would have had to replace, well, just about everything in order to put in a new derailer. In fact it would be only slightly more to simply buy a new bycycle!
So I started looking at bikes. I could get a nice road bike for $800 (US) that was far superior to my existing bike. Then I started looking at the carbon composite bikes, like the Roubaix series. I really didn't think I'd feel the difference until I test-rode one.
Holy S*it! If the $800 bike was an order of magnitude better then my existing one, the Roubaix Comp (at $2600) was an order of magnitude better then the $800 bike. All carbon-composite construction, vibration dampening... the works. Unbelievably light, I could lift the whole bike with my pinky pretty much! Smooth ride, ultra smooth shifting, huge gearing range. The technology is really amazing.
-Matt
To be really safe you need to journal to a totally different physical device then the one holding the filesystem, even possibly one on an entirely different machine or in an entirely different machine room or, if you are really paranoid, one that is located off-site.
Another advantage of a full off-machine data+meta journal is that you can reconstruct a filesystem which has been corrupted due to OS or hardware glitches.
-Matt
good tips except for #4, which I would disagree with quite strongly. Built-in flashes usually produce horrible results but a mounted flash bounced off the ceiling produces quite excellent results (and if you can't do that, a using a diffusor is your next best option). While it takes time to learn, controlling the flash exposure can produce really excellent results. You definitely do not want to bump up the ASA setting, at least not too much, because that will result in horrible digital noise and greatly reduce your post-processing options. The important thing to remember when using a flash on a digital camera is simply to avoid washing out the detail in the picture and not blowing up the white balance too badly (bounce and diffusor make a huge difference in how the results look). Most anything else can be fixed in gimp or photoshop. (e.g. the balloonman url I posted earlier is an example of an unedited photo which contains sufficient contrast, low noise, and detail to be very easily editable in gimp or photoshop for production output).
Even a point-and-shoot's flash will produce reasonable shadow fill results for daylight photos. Try this experiement: In bright sunlight take a picture of a friend's face where part of his face is significantly shadowed (e.g. by his hair or the angle of the sun). Take the picture with and without the flash, then load both into gimp or photoshop and see how well you can clean them up. You will find that you can clean up the fill-flashed picture a lot more easily.
Example #2: open your garage door and from inside the garage take a photo that includes portions of the inside (in shadow) and outside (in the sun) of the garage. Do this with and without fill flash and bring them into gimp/photoshop. You will find the fill flash photo a lot easier to clean up.
-Matt
It took me a while to learn how to use the 420EX, but it's really easy once you've played with one for a while. I started out locking the exposure at 1/200 but once I realized that automatic flash compensation actually worked properly in Manual mode I pretty much just use Manual mode (with the 10D, I don't think it works with the 300D) for late afternoon/evening/night flash shots, and Av for daylight shadow fill flash shots. (You have to use something that controls the aperture when using this particular Sigma lens because it has very bad distortion at low F-stops... but it's an excellent lens at F4). I wish the wireless 5xx series didn't cost so much (you need an additional expensive piece of equipment to actually use it in wireless mode), else I'd have someone hand-holding a second flash to get better coverage.
Flash brackets are just too imposing, I hardly ever use mine any more (the 10D with the flash and Sigma 20mm lens alone is already almost too imposing for casual shots).
And, as for the silly anonymous posters denegrating my wonderful balloonman shots :-), well, they can kiss my ass for all I care, and put up some URLs with their full blown non-thumbnailed shots if they care to compare casual pics. I didn't edit any of those photos and there's plenty of contrast there to work with. The glossy prints look very good (though the flower shots are of course much better since I didn't have to deal with a near pitch black warehouse), and most of those were taken wide frame for crop-down purposes anyway. But, of course, those anonymous bozos don't understand any of that so I don't even know why I bother trying to explain it to them.
-Matt
I have a funny story about my attempt to take a picture with my old G2 of my buddy snowboarding down the hill towards me.
So here, he comes... looking good, I hold down the shutter button hoping to get a few shots off. I've taken into account the ~1 second lag.
But there is no click. Here he comes, heading right towards me... no click. no click. no click... he's past me. I drop my arm down in disgust (still holding my finger down on the shutter release), not one shot was taken!
Then I hear a click (the camera just took a shot of my feet!), and realize what happened. The camera had been unable to autofocus on the target moving towards me. It kept trying, and kept failing.
Of course the G2 is quite old by now. But it's still a funny story.
-Matt
So the only difference in cost is the body and storage, and while it is true that a digital body costs more then a film body, it isn't on the order of 'thousands of dollars'. More like around a thousand dollar difference, tops for a good prosumer digital SLR. High-end digital SLRs such as the Canon 1Ds are certainly far more expensive, but their prices have been coming down steadily. All the professional photographers I know have switched to digital (though many keep a film camera around for traditional black and white shots), and for good reason: they can produce pictures that are just as good for most particular purposes, and it takes far less time to prepare the shots for printing then it does for film and that time factor alone more then makes up for the difference in cost, even for a high-end SLR.
Film is dead. Actually, film died a while ago, it's just taking awhile for the old farts to realize it.
-Matt
Here are some more examples of flash shots. My parent's maintain a wonderful garden and they were on the Secret Garden Tour in Berkeley this year. I took a lot of shots of flowers. Unlike the NextFest shots, which were in a dark warehouse, nearly all of the garden shots were in bright sunlight. Proper use of the flash filled in the shadows and narrowed the contrast range, producing some incredible flower shots.
I should have saved some of the test shots I took with and without the flash but I didn't. Suffice it to say that most of these shots would not look anywhere near as good as they look without the flash to provide shadow fill.
Secret Garden Tour Shots
(1) Get a good bounce flash, e.g. like the Canon 420 EX for Canon EOS cameras.
(2) Get a diffusor ($0.01 worth of milky plastic, usually $5-$10 retail). For most shots either bounce the flash off the ceiling or use the diffusor. Never use a direct-pointing flash unless you have no choice (e.g. shots from a distance).
(3) Learn how to properly use Tv, Av, and Manual modes with the flash to properly fill the image. I generally either use Av with the flash sync fixed at 1/200, or Manual mode to control how much of the shot is from natural light and how much is from the flash (on the Canon the flash exposure is automatic when operating in manual mode though for obvious reasons you have to be more careful about its exposure range capabilities).
(4) The proper use of a flash for fill is even more important in bright sunlight due to the huge contrast between shadow and sunlight (especially on faces). I almost universally use the flash with the diffusor for daylight shots.
And that's pretty much it. Most people don't use flashes properly, but it doesn't take much exposure :-) to at least double and maybe even triple the number of good shots you take in a day. As usual, I just happen to have some great examples:
The BalloonHat guy at NextFest
-Matt
There was no receipt, no way to determine after the fact whether my vote actually made it out of the polling place, or even if it was properly recorded. The machines should never have been allowed to be used in the first place.
-Matt
Flower shots from my folks Garden
All of these pictures were taken with my Canon-EOS10D, 420EX flash (used mainly for shadow fill), and Sigma 20mm 1:1.8 EX DG prime lens. The shots were taken hand-held in AP mode using F4.0-F16 depending on the conditions. This particular lens produces ultra sharp results at F4.0-F13 or so. The 10D (and 300D) use a 6 MPix low-noise CMOS sensor and you can see it in the above shots.
Insofar as all the discussion goes, from my point of view it all comes down to three things: Lens Quality, Sensor Quality, and Dynamic Range (of the exposure). SLR's like the 10D have gotten good enough that I don't use film any more. The lens quality is there (being an SLR and taking the same lens as the film EOS's), sensor quality is there, and while dynamic range still needs another 2-4 bits of resolution for my comfort it's still good enough for 99% of the shots I take. Film is dead, digital rendition at 11!
And I tend to agree with the few other obviously experienced comments (verses the bozo comments from people that don't know jack about taking photographs). You first need to know how to take a picture before you can take a good one. Then comes lens and sensor noise. A lens hood is important, and a good flash (articulated for bounce shots and also be sure to have a diffusor handy) is very important (even when you don't think you need it). For example, most of those flower shots I took were with flash+diffusor, even though it was a bright sunny day outside. The flash was used primarily to fill in some of the shadow (one way to correct for limited dynamic range but it also makes the shots look a lot better).
-Matt
My advise: don't bother trying to find equipment that can handle Jumbo frames. Most unmanaged GigE switches don't, and equivalent managed switches (many of which do handle Jumbos) are priced at a premium over their unmanaged brethren. You should only buy a managed switch if you actually need a managed switch. It takes a lot of effort to configure a network to use Jumbo frames for certain links and not for other links, and it just isn't worth it 99.9% of the time. If you want performance, focus on smart GigE cards that offload a good chunk of the packet processing (e.g. like checksum calculations and fragment reassembly). The Intel cards are a good start.
As to whether your network needs GigE or not... well, it depends on what you are using your network for. I use NFS all over my network and with GigE I get virtually the same disk performance over the network that I get with local disk. I also run backups over the LAN and the backups that run over GiGE go a lot faster then the ones that run over 100BaseT. Even more to the point, I've started distributing video over the network and 100BaseT just doesn't cut it for more then two or three streams.
If you are going to buy a new switch, you might as well get a GigE switch.
-Matt
-Matt
In terms of batteries... you only ever use batteries if you are off-grid or if the grid is really unreliable. If you are tied to the grid you do not usually use batteries... the Solar system goes through an inverter and powers the house, and any excess is fed back to the grid (running your meter backwards). The grid acts as the 'battery' in this case. If you are not producing enough to power your house, the remainder is fed to you from the grid. Grid-tie systems without batteries are the *simplest* and *cheapest* type of PV system you can buy, but you are still talking about $15-$20K for the system you see above. Systems with batteries cost a lot more (add another $5-$10K at least) plus you have maintainance requirements (Batteries wear out), and you need an ATS (Automatic Transfer Switch) which itself is expensive. On the otherhand, systems without batteries are nearly 100% maintinance free. Without batteries means that if the grid goes down, you go down too. Most people live in areas where the grid is reliable enough that there's no point doing battery storage. Also keep in mind that battery systems have much higher losses then grid-tie systems because you have a loss charging the battery and another one pulling energy out of the battery on top of the inverter losses.
Typical home AC systems eat 3kW while larger home systems eat 5kW (for homes, not apartments). Lets say you had an AC unit that eats 3kW while operating. A 2.5KW grid-tie system producing 16KwH/day would be able to run such a unit for 5 hours. As you can see, the PV system itself would not be able to power the AC unit alone, it would definitely need help from the grid, but if you only ran the AC for 5 hours the PV system would run your meter backwards the rest of the time and make up for it.
Five hours is not usually enough running time to really be able to cool a house unless you live in dessert conditions where it gets cold at night, in which case you really need to cool the house down at night so it stays cool enough so you don't have to turn on the AC until the afternoon (12-5p.m.)
So, generally speaking, trying to run an AC system with a PV (solar power) system is a bad investment. You could try running a smaller AC system but the sun generates something like a kilowatt of heat per square meter and it will easily overpower a small AC system if you do not have good insulation. Note, in particular, that if you do not have good wall insulation the sun is likely to overpower your AC during the afternoon when the sun is hitting the side of the house instead of the roof.
You would be far wiser to invest in passive technologies such as improved insulation and infra-red reflective shading. If water is cheap (or even if it isn't), a swamp cooler (rooftop evaporator) is often a great investment... it's cheap and it provides some cooling at a far lower cost then AC in electricity use. I've heard people mention GeoThermal, and it does work, but if GeoThermal is not put in when the house is actually built it can't take advantage of an under-the-house installation. Getting enough suds out o
The serializing tokens used by DragonFly work differently. They only guarentee serialization while the thread holding the token is actually running. Other threads holding the same token will be allowed to run when the first thread blocks or switches away synchronously, and the original thread will not get the cpu back until the tokens it is holding are available again.
This means that threads can obtain tokens in any order they wish, and that threads can hold tokens across blocking situations or calls to other subsystems without having to tell those subsystems about it. It may seem like a small thing, but the result is a huge simplification of the programming model. The tokens act almost like mini-BGL's (Big Giant Locks) but have the added advantage of protecting against interrupt threads trying to hold the same token. We are planning to expand the token idea further into a shared/exclusive model. The shared/exclusive model would have characteristics very similar to RCU.
The actual internal implementation of our token code is also quite a bit more flexible, allowing us to rip the guts out and rework it as needed for performance without changing the abstraction.
-Matt
I don't think it's anyone's design in particular, but I tend to sit down and write things from scratch rather then copy other people's ideas. In the case of the thread replication used by the network stack, it is primarily Jeffrey Hsu's work and since he is big on reading papers I'm sure it's a combination of his own design and ideas gleaned from various published papers.
In regards to cache issues, lets say you have a quad opteron system. Each cpu has a 1MB L2 cache. If you migrate threads willy nilly you basically wind up in a situation where each of the four cpu's L2 caches contain the same data. In effect, you wind up with a system that globally has only a tad more then 1MB of L2 cache. If you partition data (such as TCP protocol data) across distinct threads, and place those threads on different cpus, then you are in effect partioning your system's memory across all four cpu caches and you wind up with a system that globally has 3-4MB of L2 cache instead of 1-2MB.
There are two costs being saved here. (1) the cost of having to go to main memory when a piece of data is not in the L1/L2 cache, which can run into the hundreds of cpu cycles, and (2) the cost of cache mastership changes for all the data associated with the thread that was migrated (repeated each time the thread migrates).
-Matt
The LWKT scheduler on any given cpu is only allowed to operate on threads owned by that cpu. If you attempt to wakeup a thread owned by a different cpu, an asynchronous IPI message is sent to the target cpu's LWKT subsystem requesting that the specified thread be woken up. It's really that simple. Same goes for cross-cpu scheduling.
IPI messages themselves are lockless and require no mutexes to operate because the cpucpu messaging uses a software crossbar (array of FIFOs) approach.
Kernel threads almost universally stay on the cpu they were originally assigned to. High performance threaded subsystems, such as the network stack, are replicated. That is, the network stack creates multiple threads (one per cpu) and those threads do not migrate because, obviously, they do not need to.
Generally speaking, the purpose of making thread migration explicit instead of automatic is to partition a larger data set across available cpu caches rather then cause the same data to be shared amoungst all cpu caches. The processors operate a lot more efficiently and SMP scales a lot better. Most people do not realize the horrendous cost of moving threads between cpus because the cache mastership change is invisibly handled by hardware, but the cost is still there and still very real.
-Matt
A lot of consumers want 64 bit computing and 32 bit compatibility. I want it... I have several Athlon64 boxes already. Gamers very definitely want it. Intel has been able to maintain an edge primarily through fab (chip feature reduction) tricks. AMD actually has the better design and they have had it for over a year.
If you don't believe me then perhaps you are unaware of the advances that have made to the insides of cpus in recent years. AMD more then holds its own. Here is a URL ref describing the Opteron's internal logic.
AMD Opteron Architecture
Even medium format is taking a beating. Something like the EOS-10D (which I have) may not quite have the color depth or contrast to beat medium format, but the Canon sensor has virtually no noise and plenty sufficient resolution to take probably 70%+ of medium format's market share, and the convenience is two-orders of magnitude greater then anything you will ever get with any sort of film-based system. Hell, it's even more convenient to take multiple shots and stitch them together for poster-sized HR output then it is to use a medium format camera. I take thousands of shots now where I used to only take hundreds with my film SLR.
The new generation of photoprinters, like the i960, is probably an even worse indicator for Kodak. While it is still less expensive to send your digital photos off to a professional shop for printing the fact of the matter is that high quality consumer printing technology is now widely available and that spells doom for traditional companies like Kodak which depend on marketshare and volume to make their money. Photoprinting is now a market that cannot be 'cornered'.
In anycase, I wrote up a review of my 10D which is available:
Canon10D review
-Matt
Once world is installed do a 'make upgrade' to unconditionally copy files that sysops are not supposed to modify, like /etc/rc* and /etc/rc.d/*. Do this before doing the mergemaster, it will make the remaining merge a lot easier and also get rid of a ton of 4.x junk files that are either no longer used or have been moved in DFly. Hmm, you might have to wipe (rm -rf ) your /usr/include
and 'make includes' to generate a new set to get rid of old 4.x junk files in the include dir too. You will want to install new boot blocks as well, though this is not required. DFly has backported 5.x's new boot loader which is a whole lot better then 4.x's, and you get some spiffy ascii art too.
Really the best thing to do is to download and burn the DragonFly Live CD ISO, boot your machine from the CD, and follow the README file to completely wipe and reload your box with DFly. Obviously make a backup of your old system first :-). If you just want to play with DFly without messing up your HD, you can boot the CD and play around a little from there (keeping in mind that /tmp and /var and /etc are MFS volumes). The CD boots into a fully operational environment.
DragonFly
-Matt
I've seen companies go down this road before. In many respects it is a holdover from the pre-internet days (or the pre-widely-dissemenated-internet days), where companies could obfuscate facts and possibly succeed in their absurdities simply due to a lack of collaboration and coordination by their opponents. But in the age of the internet, the truth becomes viral and companies like SCO and VeriSign have a much harder time playing the system.
This isn't to say that the Media has clued in yet. Up until recently SCO got only glowing reports from investment media sources and research, primarily because most media and research sources simply parrot official press releases from the company and the open-source community has no 'official' source. But even the total idiots writing the glowing press articles are finally clueing into SCO's criminality. Not enough of them, yet, but the tide is turning.
-Matt