The thing is that aperture size is specified as f/n, where n is the aperture number and f is the focal length, so the aperture number is not a direct measure of aperture size. Consider that a P&S digital camera uses a focal length (f) of 8 mm to give equivalent zoom as a digital SLR camera would get with a 38 mm focal length, and a 35 mm film camera would get with a 50 mm focal length. Give them all an aperture number of 6, so the aperture sizes are respectively 1.33 mm, 6.33 mm and 8.33 mm. The film and digital SLR cameras get similar depth of field, but the digital P&S camera has a much smaller aperture size, and so has much greater depth of field.
For reference, cheap digital P&S cameras typically have zoom lenses with focal lengths ranging from 3-50 mm, depending on the sensor size and zoom range. Minimum aperture numbers are usually between 2.0 and 5.6, with maximum aperture numbers rarely being larger than 8.0. Since they have such great depth of field at an aperture number of 8, they don't even bother putting on controls for smaller aperture sizes.
Actually, SGI is not profitable now, although they are doing much better than they were a few years ago. In the last of the MIPS only years they had trouble because they had lost focus and their products didn't have the performance edge they had had before.
I bet most of their customers are looking forward to the time when they introduce Itanium workstations. According to SGI people, they have MIPS binary compatibility, and the old MIPS programs actually run faster on Itanium processors with a runtime binary translator than they do natively on the fastest MIPS processors.
Google Labs comes up with lots of neat stuff, but it's not research, it's all practical product stuff.
Microsoft Research is well respected and does lots of original research, but has a focus on stuff that can be applied. As Clippy has shown, their ideas aren't always good, though.
IBM Research does lots of cool research that ranges from applied stuff for new products to basic scientific research in many different fields.
Accenture Technology Labs researches new buzzwords and how they can be applied to things that other people have already done. They are very good at realizing the maximal rate of return of their innovations for their corporate parent on the going forward path, though.
Actually, if you use the tweak ui program from Microsoft, you can put quick searches into IE. Microsoft stopped developing IE when they said that future browser innovation would come mainly from plugins, which are really pretty easy to write. IE is definitely the most customizable browser around, mainly because it is just a control that anything can be done with.
I still prefer Firfox, but you might as well get your facts straight. If you don't even know the competition, how can you beat them?
Which way do you not want to do it? Given that Xen and Plex86 both run Linux, they are good enough. So it's not a completely plain vanilla x86 Linux, but once AMD gets support in and Linux gets ported to that, it will be. AMD is working on some improvements to AMD64 for that. x86 isn't very good for virtualization because the hardware isn't designed for it. It's too difficult to partition the resources.
PS. They usually work by running user level code as is, and reflecting system calls to ring 1 where the guest OS runs. Or they just interpret or block translate all kernel code like VMWare does to be completely x86 compatible, even for crappy systems like Windows that need more than 2 hardware privelige levels and aren't portable. Either way, they have to call into the real Linux kernel when the guest OS actually needs access to hardware like video cards and the virtual memory subsystem.
Of course inertia means the ride won't be quite as jerky as that would indicate, but the wheels will have to speed up and slow down the rate of turning, and that will cause some jerkiness. It won't be a perfectly smooth ride.
It's going to be fastest with the corners of the wheels touching the track, and slowest with the middle of the sides touching down.
So the answer to my question is yes, the rate of turn of the wheels will change as it rolls along. In relation to your interpretation, there is transfer of kinetic energy between moving the whole bicycle forward and turning the wheels around, so the forward velocity of the bicycle will change.
There are a whole host of advantages to being local. First is that local developers work the same hours as local employees, and are able to communicate for the whole working day, except after the normal employees go home.
Second is the language issue. Even if foreign IT workers speak good english (and often they don't), they won't know all the buzzwords, corporate nonsense-speak and slang that are specific to the region.
Third is the ability to come on site. This is great for learning about requirements for development and installing the system. Also, my clients really appreciate it that I can come and support software installations and examine and fix bugs in production systems by visiting them. This decreases the turnaround time for problems.
I'd really play up the communications issues. Email is great, but all managers know that face-to-face interactions are the best for getting information to and from nontechnical users.
This is great, because it means that Lessig and Moblen can continue to work on creating the legal framework for free software. In many ways this is more important than the software itself.
This can only serve to strengthen the GPL, particularly as version 3 nears completion, with stronger protections of freedom. All of our hard work is for nothing if Microsoft can steal our code with impugnity.
MTBF can be calculated easily, in parallel. It works because MTBF ignores end of life failures. I'll draw a simple product reliability curve below:
failures \______/ ........time
That's failures versus time. Initially you have a high failure rate due to defects, then a long floor with few failures, then a ramping failure rate due to the product wearing out.
MTBF measures the rate of failures during the long floor period, and ignores initial defect failures and things wearing out. So you just get a bunch of good products running, wait until a few of them fail, then calculate the MTBF as ((amount of time) * (number of units running in parallel) / (number of failures)). 35 years is about 300,000 hours, or roughly equivalent to running 2,000 devices for a week and experiencing one failure.
That's also why MTBF is a shitty way of determining lifespan; most devices wear out way before the are expected to fail according to MTBF.
Does the rate of forward motion vary or stay constant, assuming the wheels turn at a constant rate?
It would be interesting to ride a bicycle whose wheels turned at a different rate depending upon which side was touching the ground; even more interesting if it had a fixed gear and your legs had to match the varying angular speed of the wheels.
You know that it's a stupid idea when Microsoft comes up with it. Face it, a huge tablet isn't a PDA. You can't use it where you use a PDA, it's too heavy and it sucks the life right out of your battery.
It's a much cooler thing because it runs Linux instead of Windows, but there still isn't any point at all to it.
The combination of Mono with Qt and Linux is great. The Open Source nature of these applications means that they are virtually bug free. I am glad to see that Novell is in top form once more, supporting Linux.
I have used Mono extensively and it really is great. It is not proprietary like Java, and it is a wonderful tool to use. Mono is the programming platform that will put Microsoft to rest once and for all!
Slashdot Mirror
For reference, cheap digital P&S cameras typically have zoom lenses with focal lengths ranging from 3-50 mm, depending on the sensor size and zoom range. Minimum aperture numbers are usually between 2.0 and 5.6, with maximum aperture numbers rarely being larger than 8.0. Since they have such great depth of field at an aperture number of 8, they don't even bother putting on controls for smaller aperture sizes.
I bet most of their customers are looking forward to the time when they introduce Itanium workstations. According to SGI people, they have MIPS binary compatibility, and the old MIPS programs actually run faster on Itanium processors with a runtime binary translator than they do natively on the fastest MIPS processors.
Microsoft Research is well respected and does lots of original research, but has a focus on stuff that can be applied. As Clippy has shown, their ideas aren't always good, though.
IBM Research does lots of cool research that ranges from applied stuff for new products to basic scientific research in many different fields.
Accenture Technology Labs researches new buzzwords and how they can be applied to things that other people have already done. They are very good at realizing the maximal rate of return of their innovations for their corporate parent on the going forward path, though.
I still prefer Firfox, but you might as well get your facts straight. If you don't even know the competition, how can you beat them?
PS. They usually work by running user level code as is, and reflecting system calls to ring 1 where the guest OS runs. Or they just interpret or block translate all kernel code like VMWare does to be completely x86 compatible, even for crappy systems like Windows that need more than 2 hardware privelige levels and aren't portable. Either way, they have to call into the real Linux kernel when the guest OS actually needs access to hardware like video cards and the virtual memory subsystem.
relating radius to velocity:
v=2*pi*r
dv/dr=2*pi
Of course inertia means the ride won't be quite as jerky as that would indicate, but the wheels will have to speed up and slow down the rate of turning, and that will cause some jerkiness. It won't be a perfectly smooth ride.
It's going to be fastest with the corners of the wheels touching the track, and slowest with the middle of the sides touching down.
So the answer to my question is yes, the rate of turn of the wheels will change as it rolls along. In relation to your interpretation, there is transfer of kinetic energy between moving the whole bicycle forward and turning the wheels around, so the forward velocity of the bicycle will change.
There are a whole host of advantages to being local. First is that local developers work the same hours as local employees, and are able to communicate for the whole working day, except after the normal employees go home. Second is the language issue. Even if foreign IT workers speak good english (and often they don't), they won't know all the buzzwords, corporate nonsense-speak and slang that are specific to the region. Third is the ability to come on site. This is great for learning about requirements for development and installing the system. Also, my clients really appreciate it that I can come and support software installations and examine and fix bugs in production systems by visiting them. This decreases the turnaround time for problems. I'd really play up the communications issues. Email is great, but all managers know that face-to-face interactions are the best for getting information to and from nontechnical users.
This can only serve to strengthen the GPL, particularly as version 3 nears completion, with stronger protections of freedom. All of our hard work is for nothing if Microsoft can steal our code with impugnity.
That's failures versus time. Initially you have a high failure rate due to defects, then a long floor with few failures, then a ramping failure rate due to the product wearing out.
MTBF measures the rate of failures during the long floor period, and ignores initial defect failures and things wearing out. So you just get a bunch of good products running, wait until a few of them fail, then calculate the MTBF as ((amount of time) * (number of units running in parallel) / (number of failures)). 35 years is about 300,000 hours, or roughly equivalent to running 2,000 devices for a week and experiencing one failure.
That's also why MTBF is a shitty way of determining lifespan; most devices wear out way before the are expected to fail according to MTBF.
Does the rate of forward motion vary or stay constant, assuming the wheels turn at a constant rate? It would be interesting to ride a bicycle whose wheels turned at a different rate depending upon which side was touching the ground; even more interesting if it had a fixed gear and your legs had to match the varying angular speed of the wheels.
It's a much cooler thing because it runs Linux instead of Windows, but there still isn't any point at all to it.
The combination of Mono with Qt and Linux is great. The Open Source nature of these applications means that they are virtually bug free. I am glad to see that Novell is in top form once more, supporting Linux. I have used Mono extensively and it really is great. It is not proprietary like Java, and it is a wonderful tool to use. Mono is the programming platform that will put Microsoft to rest once and for all!