+1 to "learn new stuff quickly". +1 to "a little assembler". +1 "really messed up language... to see the other side".
Languages themselves matter little. Biggest hurdles are the custom libraries and business case of the company. With libraries, one has no choice other than sit down and read all the code. With business case... well one can only understand that with time: few people/few companies would openly admit that their business case e.g. is selling cheap buggy software (and that's about 90% of software development market).
My only personal advise would be to refrain as much as possible from: (1) Windows and (2) Java. They both have the effect of BASIC on programmers, rendering them impotent few years later. Or in other words: do not start career on Windows or with Java, they both quickly make developers incapable of looking outside of a box.
The only way Sony can win is if they pretend they're not competing with Nintendo, and say that the Xbox 360 will be surpassed in 10 years. This conveniently ignores the high probability that the PS3 will be completely dead in ten years if they don't do something now.
I actually agree that PS3 would outsell Xbox360 in 10 years. (Probably even Wii.) The problem for Sony here is that in 10 years, MSFT would already release Xbox1440 and Nintendo - Wiiii.
Kaz Hirai is a lunatic and he's going to run the PS3 into the ground.
Japs traditionally do things with devotion. And devoted people tend to make themselves believe in what they say.
It's not like in the situation Sony management can do anything radical. They have to balance profits with long term plans. They invested lots of time/money and have no choice but to push whatever they have for sale - at a price which has a distant chance of turning a profit.
For whatever reason PS3/BD fails - management heads in Sony would roll. It doesn't matter how it would fail - it would be spectacular. That means the management to succeed have to put a kind smile on and try to sell it more aggressively.
There are good zoom lenses out there, I just don't own any.
And Oly produces number of them too. It's just few people ready to shell out $1-2k for a good zoom.
And it wasn't about generally higher quality of primes. It was about the fact that Canikon universe is filled with dirt-cheap crappy zooms.
N.B. It was actually Oly - due to weaker sensor - which first started including with its cameras quite good standard kit zoom (14-42). At the time e.g. Canon 350D/400D kit zoom was actually worse than useless. 450D they were forced by competition to include some decently performing standard zoom.
Once you move on beyond being an Oly fanboi, you may very well (like a number of people) conclude that there is a use for larger format sensors (or film) and thus image sensors with a larger number of photosites.
That was never disputed. Topic was that 12MP is more than enough for 95+% of people. (Where you are highly likely belong: you do not talk like professional. Their post I dig non-stop for past 6 months I own the Oly.)
And there is nothing wrong for any company to go after wider market. After all, you know, Canon produces not only 1D high end monsters - but cheap plastic optics point-and-shot soap boxes too. And they sell much much more of the later.
As to Oly fanboism... Actually most professionals I read posts on 4/3 forums own also some Canon or Nikon (xD or Dx00). Oly simply doesn't produce higher end cameras - they are openly after wider market. (What is btw often criticized by said professionals.)
I'm hardly a fanboi anyway. Before Canon 1000D, from new cameras Oly E-5x0 was simply best bang for the buck. Now seeing how my friend struggles with his Canon, I'd easily take the calling of Oly fanboi. Because my Oly (with kit 14-42 zoom!) actually did usable photos, when my friend's Canon 1000D (with highly rated Tamron zoom) simply balked.
Converting from RAW is somewhat different from RAW development. Namely in the aspect that some transformations are performed without any loss of quality.
ImageMagick highly likely (and its site says it's "a software suite to create, edit, and compose bitmap images") can import RAW (with settings stored inside), and then operate on it as on plain bitmap in memory. That means when you do some operations which e.g. adjust colors you loose the quality. Because extra information present in RAW was already discarded during import.
If all you do is create thumbnails, then probably ImageMagick is OK.
But otherwise, using some RAW development tool to catalog and export final images from RAWs would generally produce better results. I personally do not like RAW development tools very much, yet I'm already addicted to stuff like EV and BW adjustments. If I do them on plain bitmap images, then after few operations in GIMP, you might start seeing artifacts. If you do them on RAWs, unless using extreme values for adjustments which exceed information stored in RAW, quality remains quite good and artifacts are negligible.
Perhaps you ought to read what I wrote instead of defending your choice of gear?
Unlike you, I did some research before buying the gear, taking into account my needs.
FWIW, I shoot a Fuji F30 (6MP) and a Nikon D200 (10MP). For available light photography, the F30 beats the pants off of the D200 and thus your E520 too. I'm quite content with not the highest resolution sensors. But for a company (or someone affiliated with them) to purport that the highest resolution you'll ever need is the top of *their* line (but not the top of others') is a bit disingenuous at best.
Ha. "Defending your choice of gear" yourself?
Stop whining and go learn some basics. What you say is precisely what I call "buzzword-headline-induced nonsense". Because unless you work in field where you need large prints @ 300dpi, 12MP is already too much.
At the moment to me (amateur) it seems that your optics is simply subpar: on 6MP with cheap optics you see much less optical artifacts than on 10MP with similarly subpar optics. Buy some good - e.g. prime - lens and try again.
Of course Olympus is saying they don't want to compete in the megapixel race. They can't.
Then can. Ask professionals who shoot with Olys and other cameras on why for 99% or people (and probably 75% pros) 12MP is sufficient.
Also do not forget that more pixels only increase the amount of data which needs to be processed, while very few application fields require the 4000x3000 sized pictures. And if you would try to push resolution even further, you would start to see more and more optical artifacts: right now most of them (most of the time) are kept under pixel size. The point is that for larger/denser sensors you would need larger optics.
Having held f/2.0 zoom lens in my hands, I think that many (even professionals) would trade the monster sensor/lens cameras for better albeit smaller sensor and smaller lens. In fact, many already doing it - especially professionals, only now converting from film to digital.
Oly is pushing the 4/3 standard which uses the smallest sensors of any common DSLR system.
Smallest doesn't mean "f*cking tiny". In fact, 4/3 is only ~30% smaller than APC-S.
And due to difference in form factor, 4/3 doesn't need cropping to be printed on standard paper sizes/viewed on standard computer screen (where about 95% of all taken photos end up being viewed).
This strikes me as similar to AMD claiming that clock speed was a bad performance metric back when their stuff was clocked slower and couldn't quite compete with Intel.
LOL. Not so ironically, with new processors Intel itself abandoned clock rate race. New i7 is clocked lower than many previous Intel processors, yet in most areas has 30+% performance advantage over them.
Do some googling/whatever instead of posting such buzzword-headline-induced nonsense...
P.S. Disclaimer. Proud owner of Oly E-520 which thanks to superior optics easily beats Canon's 450D and 1000D with usual eBay'ed lenses. Regardless of whatever DxOmark says...
JPEG compression is JPEG compression and RAW data is RAW data.
not really, there is actually lossless compression of jpeg images that will reduce size by 25% (sometimes more) from what a camera produces (not even including the removal of exif, and thumbnail removal)
You miss the point of RAW. RAW has more information than JPEG, because RAW is essentially direct dump from sensor + actual image settings. Sensors are not precisely RGB. But dumbly converting them to JPEG or PNG, you loose lots of information.
Classical example is balance of white. In JPEG/PNG it is all already pixels. In RAW you can change WB without loss of quality. Or extra bits of color, which can be used for EV (exposure value) adjustments.
It would depend on how much memory/CPU time/power the camera is willing to use. I find I get a much much better, and similar sized image post processing on my PC, than selecting at the camera. (IE minimal jpeg compression at the camera produces a larger, and noticeably worse image, than doing the downsize with imagemagic, from a full size RAW format on a PC)
ImageMagic isn't a RAW development tool.
If you want something on cheap, try RawTherapee or GIMP+dcraw (on Linux; GIMP + UFRAW on Windows). With GIMP/dcraw, you would be able to adjust RAW parameters ("develop a RAW") during import and then in GIMP do whatever you like with result of development.
I have traditionally associated this with Windows or MacOS, but it is happening with Linux as well. Environments have little or no support for multi-language projects - you choose a language, open a project and get it done.
Probably because more and more people start using Linux to do some real work? It's not for geeks/nerds/engineers anymore.
But see below.
Recent trends in more targeted build environments like cmake or ant are understandably focusing on automatic dependency generation and cross-platform support, unfortunately making it more difficult to grow a custom build process for a multi-language project organically.
It's old, but it works - GNU Cons. Also Google for "pcons", its parallel version.
All this is a bit painful for me, as I know how much is gained by using a targeted language for a particular problem. Now the question: Should I suck it up and learn to do all my programming in C++/Java/(insert other well-supported, popular language here) and unlearn ten years of philosophy, or is there hope for the multi-language development process?"
This is like "Emacs vs. vi". There are people who to do work need well integrated environment. And there are people who prefer to have bunch of lego blocks and make from them whatever fits better task at hand.
Approach of building integrated, all-in-one, probably language-dependent software is nothing new and expected step in evolution of more or less any software product.
Main reason is that integrated systems have lower entry barrier. Essentially, people get some well-controlled sandbox where nothing can go wrong. Mostly because they do not want to learn - or do not have the time for it. Slap some task oriented UI on top of all of that - and any with knowledge of application field would be able to do his work with the software.
It's kind of funny that somebody brings it up again. Many people in past were dooming *nix to extinction because learning curve (and need to learn *nix philosophy too) is quite steep. Some bits about that are scattered around in ESR's TAOUP.
The only advise I can give you is to look out for application fields where your expertise with *nix and scripting can be advantageous and then change job. But honestly, I still can't recall single company where I did not end up writing bunch of small programs/scripts for whatever internal needs people have. Was it DOS, Windows, Linux or *nix, needs are the same. Even more so when people standardize on some all-in-one solution: I have never seen perfect one, which didn't required some custom hacks.
In the end, from my experience, expertise in making hacks - in making workflow more efficient - is well appreciated. Though more in smaller companies than in larger companies. Just do not limit yourself to Linux, and you'll be fine.
UHMMM you're contradicting yourself dude. "Most compatible Nix clone" with what, itself? That's not compatibility. That's Microsoft-style compatibility.
Uhm... next time you should have tried to read the whole thread.
"Compatibility" I have talked about was in context of UNIX'03 certification and Linux's lack of it.
P.S. I also do not like when people write off something as bashism/gnu-specific stuff. If improvements do really help everyday's work, why the heck the *BSD nuts religiously refuse to add them?? How many decades it took them to add '-r' to grep? '-iname' to find??? I glad that they added them now. But force people to wait a decade for no good reason? And "burning at stakes" those "GNU/FSF heretics" who wanted to improve things?.. That's plain retarded.
Though overall *BSDs sport superior development environment, yet seeing that the environment yields so little of end results is really appalling. GNOME/KDE/X.org/etc use Linux as their native platform for the reason.
Someone still has to have it certified and it still wouldn't pass the certification because there are still missing features.
List of missing features in studio, please.
I'm working on bunch of *nix systems, and frankly Linux always stroke me - software developer - as most compatible *nix clone. Essentially bunch of stuff (written after SUSv3) simply works on Linux while on e.g. Solaris some stuff is either buggy or simply missing or in different "UNIX traditional" header.
Shortly, looking into SUSv3 and programming on Linux works. But it doesn't on true-UNIX Solaris and *BSD.
I'm kind of also happy that Linux is not *nix. Having worked on FreeBSD for some short time, it's simply impossible to be as efficient with their antique true-UNIX text/file tools as one can be with GNU text/file tools. Needless to mention that on *BSD/bin/bash isn't default shell, line editing isn't always there, no usable pager and no decent text editor is installed by default. On fresh Linux install one can start working already. On fresh *BSD setup - you have to start compiling ports. Feel the difference.
If one tried to treat Mac OS X as *BSD, than it makes the *BSD misery even more apparent: minority of Mac OS X users ever bother to use the command line. Had it been something useful, I bet more people would have used it. On Linux, e.g. on Ubuntu you rarely (if ever with recent version) have to go to command line. Yet people use it - because it is usable and useful.
It's unfortunate that the package was broken, though compiling your own version will not void any service contracts.
They can't void service contract.
Disclaimer: I never used RHEL, only talked in past on several occasions with frustrated users. (Frustration mainly coming from the fact that they expected more freedom from RHEL, yet in the end got pretty much the same deal (albeit cheaper) as from proprietary *nix vendors.)
I was under impression that if RH support finds some custom build application, they would first ask to remove it (or restore system from backup) before they would start actually helping your with problem. At least I know of one such case with custom build Apache server.
1. IMHO, at the moment, Apple offers the best quality PC you can get for money. Though I'm not a fanboi since I also generally take into account that money is (very) limited entity. If you are in market for tool with particular price/performance ratio, than Apple is definitely not for you. Yet, Apple "Just Works" with much higher probability than M$ or Linux powered systems. (Though with some vendors' systems Linux too reached the point of "Just Works".)
2. It happens all the time to Microsoft. Mostly because of their archaic, backward APIs they never really even attempt to clean up or provide clean way to access particular functionality. As Microsoft vs. fanbois case goes, it's more like everybody hates to be the slave of the M$ release strategy. And hey, I'd love to "murder" M$ too, since I'm dealing with the crap on daily basis.
Since M$ always sees the end-users of Windows only as a number on an accounting sheet, there are no true M$ fanbois (only people who forced themselves to like it because they have no choice). So obviously fanboism-wise there is a bias toward Apple (which sometimes actually listens to the unfiltered feedback from its users).
This is not a first Apple's blopper. Any OS vendor might have those.
The question is how long would it take for Apple to fix that. In the blog post linked Fedora Perl issues actually took about year to deliver fix for RHEL.
While compiling and using your own build of Perl (or using Fink) on Mac OS X is absolutely OK, under RHEL that might easily screw up your RH support contract...
If you want to have a stand against management intervention, your only choice is to be on the same level as they are... I've being in the situations like that before - with no positive experience to share.
What management tries to accomplish is generally well intended. If one team profits greatly from some tool - they'd try to make the tool available to other teams. Essentially, as your tool grows in its importance to company, so must you. This is also a good promotion chance (e.g. to get "Sr." or "Principal" or "Key" prefix to your actual position name).
One shouldn't forget in the situation old saying: one man's problem - other man's opportunity. But of course to catch the opportunity you have to understand well why management is getting involved. It's really worth asking: management when on some agenda generally very talkative.
I'd hate it. I'd be much less productive.
This is very old stereo-type. You just have to learn instead of lines of code to manage people. Imagine that you have not one but two pairs of hands? And how much more could you do with twice more hands? Yep, that's what management ideally is.
There must be companies that recognize what a good engineer is worth, but I've yet to see one that paid them more than management.
Some really talented engineers might have higher salaries than management. I have seen it. Once.
Low/middle tier managers are the people who are responsible for executing business plan of the company. Upper management - and their vision for product development, business plan - is what creates work for engineers. The company as a whole what makes of faceless technology/tool a product others want to fork money for. And the money - are the wages.
Consequently engineers generally do not influence directly the profits, thus they have lower wages when compared to management. (And unlike old "chicken or the egg problem", here it is clear: management is first, because they have created from ground zero a company.)
There are countless - failed - products around. Failed solely because people who did them didn't bothered to communicate with customers, releasing essentially gimmick nobody needs.
Healthy discussions with customers about shortcomings of a product, followed by inside discussions on why product ended up released in that way. That's how companies survive in long term: by making something others want to buy.
This entire discussion is a sign of poor hiring by the company involved. If they want innovative people they should hire innovative people. It isn't that hard - look for people who have done innovative things in the past and pay them money to work for you.
That's just plain stupid.
Sorry for the oxymoron, but all people are born innovative. True managerial talent is to get the innovative nature out of people for good of business.
General problem with hiring "innovative people" is that most of them can't keep on the same piece of work for very long time. Innovation is matter of a short moments. End product - is thousands person/days of many many employees. Few truly innovative people can stick to the business routine. And very few companies go to compromise and provide innovative people with sort of isolated environment - where they are isolated from usual business routine related to making of a product.
The rest is just common sense: give them the responsibility and resources to achieve change, think twice before screwing them over, and expand the scope of their resources (personal or departmental) as they deliver results.
That's common sense. Yet your base off by far.
Responsibilities is what used to keep people in check. Yet, not much people are capable of bearing responsibilities. If one can - then they'd likely to choose managerial career. That means rest of "innovative" bunch is precisely the people who can't manage, can't cope with responsibilities and rarely can work under pressure. In other words - rest of us, employees.
That's why proper communication with employees is needed. General problem that many managers can't cope with critique of their decisions. Eventually any kind of critique falls under unwritten ban leading to dried up communication within company.
Oh lets fire the janitor because his suggestion on how to improve productivity has failed.
Corrected version:
Oh lets fire the janitor because his suggestion I have plagiarized on how to improve productivity has succeeded.
And I personally think that giving away bonuses would only increase tension and discrimination inside of teams.
I prefer simpler idea suggested above: permit to criticize management and their decisions. Ban on criticism is essentially what most often leads to disappearance of discussions. Healthy discussion is what drives innovation.
GPUs excel at tasks that map N input values to one output value, with a minimum amount of unpredictable branches. If a task fits in this well, it is likely being accelerated already, via CUDA, Stream, CTM. If it doesn't fit, forcing it on the GPU is a waste of time.
I understand your sentiment - as software developer.
Yet, if you look at situation from nVidia pov, all what you say are real disadvantages of GPU compared to CPU. Trying to improve in the areas for nVidia is only logical - to compete better against Intel/AMD. Probably even more against AMD than Intel.
While Intel and PS4 are pretty much wild speculation - based on logic (Intel is specialist in cheap chip production, something Sony urgently needs for its PS3), the nVidia and x86 are based on hirings.
While I will not go as far as to say that nVidia is attempting to implement whole CPU, it could be that they are trying to put CPU emulator/accelerator on to GPU. Scrapping the shader language and allow to write/compile plain C/etc which can be run unmodified on both CPU and GPU is a huge step forward to allow hybrid/partial acceleration, scaling the technology from lowest-end to highest-end.
Both moves have logic behind them. Both are speculations. First was already denied. But let the soap opera run for few more episodes^W the Inquirer articles more.
Style-wise, KDE never hid fact they were using best off Windows design. In past times - KDE 1/2 and GNOME 1 - GNOME was pitched as *nix thing and KDE as something imitating to Windows UI.
What I meant by the comparison is development model. KDE is quite decentralized. Only handful of applications are written by the core KDE team (which has number of people from Qt team). Most applications - most of KDE innovations - they happen outside of core and they are what most users see.
Now in Windows and GNOME part of universe, you would see strong commercial support and consequently centralized management of the projects. MS controls Windows. RH/Suse/Sun control GNOME. The parties control more or less completely what gets included and when new releases happen. (e.g. RH syncs releases of GNOME with releases of Fedora).
That's why KDE folks loosely follow strategy "release more, release often" while GNOME follows strategy "release on schedule; drop features if needed." Needless to point that latter is MS Windows release strategy too.
Ah, thanks for the information! It hadn't even occurred to me that something like this would be configurable. Is there a reason it's disabled by default? It seems the only people who wouldn't want it enabled would be those who don't use keyboard shortcuts, and it wouldn't impact them in any case.
Never ever I had problem under Mac OS X when e.g. cleaning keyboard when computer is still on. Or simply by accident palming half of keyboard.
I wouldn't recommend that on Windows - and especially on Linux. Results might be surprising or (worse) unrecoverable.
I'm still in awe of Apple's genius for making "Enter" key not to open/start selected file/program. (Cmd-O does that in Mac OS X). I had crashed Win95 this way once: pressed Ctrl-A thinking I was in WinWord, but desktop was selected; then pressed quickly "Enter". Windows naturally tried to start all applications with shortcuts on desktop. Logical - yet stupid.
The fact that in all MS programs you can never resize those popups with too-wide info [...]
I'm not sure what you talking about. Care to provide example? It is actually bothering me as well because now even KDE and GNOME started inhibiting windows resizing.
All I can say that you can try "high contrast" settings. I can attest that all MS produced Windows programs are working perfectly fine under the rather unusual settings. Also, "large fonts" option was always supported by MS applications perfectly. (Now it has different name - lazy to search).
On 3rd party application front this is... different. Expect various breakages and crashes when using "high contrast" and/or "large fonts". Having been in Windows developer shoes for 5+ years, properly guessing actually activated accessibility options was very fine art. Carefully selecting used graphics functions - as to make application capable of running in the modes - was more of a torture than work.
Slashdot Mirror
Not really. They have their own H/W design department. They do not manufacture themselves - that's fact. But they design themselves.
Another fact: keyboard/mice/etc H/W design team has ZILCH/ZERO/NADA in common with Xbox* design team. They belong to different business units.
+1 to "learn new stuff quickly". +1 to "a little assembler". +1 "really messed up language ... to see the other side".
Languages themselves matter little. Biggest hurdles are the custom libraries and business case of the company. With libraries, one has no choice other than sit down and read all the code. With business case ... well one can only understand that with time: few people/few companies would openly admit that their business case e.g. is selling cheap buggy software (and that's about 90% of software development market).
My only personal advise would be to refrain as much as possible from: (1) Windows and (2) Java. They both have the effect of BASIC on programmers, rendering them impotent few years later. Or in other words: do not start career on Windows or with Java, they both quickly make developers incapable of looking outside of a box.
[...] it is a given that a tool such as the DMCA **WILL** be abused to silence opposition or competition...
Abuse? ABUSE????
Wait a minute.
You mean that isn't its intended use????
The only way Sony can win is if they pretend they're not competing with Nintendo, and say that the Xbox 360 will be surpassed in 10 years. This conveniently ignores the high probability that the PS3 will be completely dead in ten years if they don't do something now.
I actually agree that PS3 would outsell Xbox360 in 10 years. (Probably even Wii.) The problem for Sony here is that in 10 years, MSFT would already release Xbox1440 and Nintendo - Wiiii.
Kaz Hirai is a lunatic and he's going to run the PS3 into the ground.
Japs traditionally do things with devotion. And devoted people tend to make themselves believe in what they say.
It's not like in the situation Sony management can do anything radical. They have to balance profits with long term plans. They invested lots of time/money and have no choice but to push whatever they have for sale - at a price which has a distant chance of turning a profit.
For whatever reason PS3/BD fails - management heads in Sony would roll. It doesn't matter how it would fail - it would be spectacular. That means the management to succeed have to put a kind smile on and try to sell it more aggressively.
There are good zoom lenses out there, I just don't own any.
And Oly produces number of them too. It's just few people ready to shell out $1-2k for a good zoom.
And it wasn't about generally higher quality of primes. It was about the fact that Canikon universe is filled with dirt-cheap crappy zooms.
N.B. It was actually Oly - due to weaker sensor - which first started including with its cameras quite good standard kit zoom (14-42). At the time e.g. Canon 350D/400D kit zoom was actually worse than useless. 450D they were forced by competition to include some decently performing standard zoom.
Once you move on beyond being an Oly fanboi, you may very well (like a number of people) conclude that there is a use for larger format sensors (or film) and thus image sensors with a larger number of photosites.
That was never disputed. Topic was that 12MP is more than enough for 95+% of people. (Where you are highly likely belong: you do not talk like professional. Their post I dig non-stop for past 6 months I own the Oly.)
And there is nothing wrong for any company to go after wider market. After all, you know, Canon produces not only 1D high end monsters - but cheap plastic optics point-and-shot soap boxes too. And they sell much much more of the later.
As to Oly fanboism... Actually most professionals I read posts on 4/3 forums own also some Canon or Nikon (xD or Dx00). Oly simply doesn't produce higher end cameras - they are openly after wider market. (What is btw often criticized by said professionals.)
I'm hardly a fanboi anyway. Before Canon 1000D, from new cameras Oly E-5x0 was simply best bang for the buck. Now seeing how my friend struggles with his Canon, I'd easily take the calling of Oly fanboi. Because my Oly (with kit 14-42 zoom!) actually did usable photos, when my friend's Canon 1000D (with highly rated Tamron zoom) simply balked.
Converting from RAW is somewhat different from RAW development. Namely in the aspect that some transformations are performed without any loss of quality.
ImageMagick highly likely (and its site says it's "a software suite to create, edit, and compose bitmap images") can import RAW (with settings stored inside), and then operate on it as on plain bitmap in memory. That means when you do some operations which e.g. adjust colors you loose the quality. Because extra information present in RAW was already discarded during import.
If all you do is create thumbnails, then probably ImageMagick is OK.
But otherwise, using some RAW development tool to catalog and export final images from RAWs would generally produce better results. I personally do not like RAW development tools very much, yet I'm already addicted to stuff like EV and BW adjustments. If I do them on plain bitmap images, then after few operations in GIMP, you might start seeing artifacts. If you do them on RAWs, unless using extreme values for adjustments which exceed information stored in RAW, quality remains quite good and artifacts are negligible.
Perhaps you ought to read what I wrote instead of defending your choice of gear?
Unlike you, I did some research before buying the gear, taking into account my needs.
FWIW, I shoot a Fuji F30 (6MP) and a Nikon D200 (10MP). For available light photography, the F30 beats the pants off of the D200 and thus your E520 too. I'm quite content with not the highest resolution sensors. But for a company (or someone affiliated with them) to purport that the highest resolution you'll ever need is the top of *their* line (but not the top of others') is a bit disingenuous at best.
Ha. "Defending your choice of gear" yourself?
Stop whining and go learn some basics. What you say is precisely what I call "buzzword-headline-induced nonsense". Because unless you work in field where you need large prints @ 300dpi, 12MP is already too much.
At the moment to me (amateur) it seems that your optics is simply subpar: on 6MP with cheap optics you see much less optical artifacts than on 10MP with similarly subpar optics. Buy some good - e.g. prime - lens and try again.
Of course Olympus is saying they don't want to compete in the megapixel race. They can't.
Then can. Ask professionals who shoot with Olys and other cameras on why for 99% or people (and probably 75% pros) 12MP is sufficient.
Also do not forget that more pixels only increase the amount of data which needs to be processed, while very few application fields require the 4000x3000 sized pictures. And if you would try to push resolution even further, you would start to see more and more optical artifacts: right now most of them (most of the time) are kept under pixel size. The point is that for larger/denser sensors you would need larger optics.
Having held f/2.0 zoom lens in my hands, I think that many (even professionals) would trade the monster sensor/lens cameras for better albeit smaller sensor and smaller lens. In fact, many already doing it - especially professionals, only now converting from film to digital.
Oly is pushing the 4/3 standard which uses the smallest sensors of any common DSLR system.
Smallest doesn't mean "f*cking tiny". In fact, 4/3 is only ~30% smaller than APC-S.
And due to difference in form factor, 4/3 doesn't need cropping to be printed on standard paper sizes/viewed on standard computer screen (where about 95% of all taken photos end up being viewed).
This strikes me as similar to AMD claiming that clock speed was a bad performance metric back when their stuff was clocked slower and couldn't quite compete with Intel.
LOL. Not so ironically, with new processors Intel itself abandoned clock rate race. New i7 is clocked lower than many previous Intel processors, yet in most areas has 30+% performance advantage over them.
Do some googling/whatever instead of posting such buzzword-headline-induced nonsense...
P.S. Disclaimer. Proud owner of Oly E-520 which thanks to superior optics easily beats Canon's 450D and 1000D with usual eBay'ed lenses. Regardless of whatever DxOmark says...
JPEG compression is JPEG compression and RAW data is RAW data.
not really, there is actually lossless compression of jpeg images that will reduce size by 25% (sometimes more) from what a camera produces (not even including the removal of exif, and thumbnail removal)
You miss the point of RAW. RAW has more information than JPEG, because RAW is essentially direct dump from sensor + actual image settings. Sensors are not precisely RGB. But dumbly converting them to JPEG or PNG, you loose lots of information.
Classical example is balance of white. In JPEG/PNG it is all already pixels. In RAW you can change WB without loss of quality. Or extra bits of color, which can be used for EV (exposure value) adjustments.
It would depend on how much memory/CPU time/power the camera is willing to use. I find I get a much much better, and similar sized image post processing on my PC, than selecting at the camera. (IE minimal jpeg compression at the camera produces a larger, and noticeably worse image, than doing the downsize with imagemagic, from a full size RAW format on a PC)
ImageMagic isn't a RAW development tool.
If you want something on cheap, try RawTherapee or GIMP+dcraw (on Linux; GIMP + UFRAW on Windows). With GIMP/dcraw, you would be able to adjust RAW parameters ("develop a RAW") during import and then in GIMP do whatever you like with result of development.
Just voted for "Stewart".
I have traditionally associated this with Windows or MacOS, but it is happening with Linux as well. Environments have little or no support for multi-language projects - you choose a language, open a project and get it done.
Probably because more and more people start using Linux to do some real work? It's not for geeks/nerds/engineers anymore.
But see below.
Recent trends in more targeted build environments like cmake or ant are understandably focusing on automatic dependency generation and cross-platform support, unfortunately making it more difficult to grow a custom build process for a multi-language project organically.
It's old, but it works - GNU Cons. Also Google for "pcons", its parallel version.
All this is a bit painful for me, as I know how much is gained by using a targeted language for a particular problem. Now the question: Should I suck it up and learn to do all my programming in C++/Java/(insert other well-supported, popular language here) and unlearn ten years of philosophy, or is there hope for the multi-language development process?"
This is like "Emacs vs. vi". There are people who to do work need well integrated environment. And there are people who prefer to have bunch of lego blocks and make from them whatever fits better task at hand.
Approach of building integrated, all-in-one, probably language-dependent software is nothing new and expected step in evolution of more or less any software product.
Main reason is that integrated systems have lower entry barrier. Essentially, people get some well-controlled sandbox where nothing can go wrong. Mostly because they do not want to learn - or do not have the time for it. Slap some task oriented UI on top of all of that - and any with knowledge of application field would be able to do his work with the software.
It's kind of funny that somebody brings it up again. Many people in past were dooming *nix to extinction because learning curve (and need to learn *nix philosophy too) is quite steep. Some bits about that are scattered around in ESR's TAOUP.
The only advise I can give you is to look out for application fields where your expertise with *nix and scripting can be advantageous and then change job. But honestly, I still can't recall single company where I did not end up writing bunch of small programs/scripts for whatever internal needs people have. Was it DOS, Windows, Linux or *nix, needs are the same. Even more so when people standardize on some all-in-one solution: I have never seen perfect one, which didn't required some custom hacks.
In the end, from my experience, expertise in making hacks - in making workflow more efficient - is well appreciated. Though more in smaller companies than in larger companies. Just do not limit yourself to Linux, and you'll be fine.
UHMMM you're contradicting yourself dude. "Most compatible Nix clone" with what, itself? That's not compatibility. That's Microsoft-style compatibility.
Uhm... next time you should have tried to read the whole thread.
"Compatibility" I have talked about was in context of UNIX'03 certification and Linux's lack of it.
P.S. I also do not like when people write off something as bashism/gnu-specific stuff. If improvements do really help everyday's work, why the heck the *BSD nuts religiously refuse to add them?? How many decades it took them to add '-r' to grep? '-iname' to find??? I glad that they added them now. But force people to wait a decade for no good reason? And "burning at stakes" those "GNU/FSF heretics" who wanted to improve things?.. That's plain retarded.
Though overall *BSDs sport superior development environment, yet seeing that the environment yields so little of end results is really appalling. GNOME/KDE/X.org/etc use Linux as their native platform for the reason.
On Gentoo you by definition start compiling. It's source oriented distro where recompile of everything norm of life.
What I actually spoken about in gp were normal system tools used to do usual daily *nix routine (find, grep, vim, etc).
True. Linux is not UNIX'03 certified.
Someone still has to have it certified and it still wouldn't pass the certification because there are still missing features.
List of missing features in studio, please.
I'm working on bunch of *nix systems, and frankly Linux always stroke me - software developer - as most compatible *nix clone. Essentially bunch of stuff (written after SUSv3) simply works on Linux while on e.g. Solaris some stuff is either buggy or simply missing or in different "UNIX traditional" header.
Shortly, looking into SUSv3 and programming on Linux works. But it doesn't on true-UNIX Solaris and *BSD.
I'm kind of also happy that Linux is not *nix. Having worked on FreeBSD for some short time, it's simply impossible to be as efficient with their antique true-UNIX text/file tools as one can be with GNU text/file tools. Needless to mention that on *BSD /bin/bash isn't default shell, line editing isn't always there, no usable pager and no decent text editor is installed by default. On fresh Linux install one can start working already. On fresh *BSD setup - you have to start compiling ports. Feel the difference.
If one tried to treat Mac OS X as *BSD, than it makes the *BSD misery even more apparent: minority of Mac OS X users ever bother to use the command line. Had it been something useful, I bet more people would have used it. On Linux, e.g. on Ubuntu you rarely (if ever with recent version) have to go to command line. Yet people use it - because it is usable and useful.
It's unfortunate that the package was broken, though compiling your own version will not void any service contracts.
They can't void service contract.
Disclaimer: I never used RHEL, only talked in past on several occasions with frustrated users. (Frustration mainly coming from the fact that they expected more freedom from RHEL, yet in the end got pretty much the same deal (albeit cheaper) as from proprietary *nix vendors.)
I was under impression that if RH support finds some custom build application, they would first ask to remove it (or restore system from backup) before they would start actually helping your with problem. At least I know of one such case with custom build Apache server.
1. IMHO, at the moment, Apple offers the best quality PC you can get for money. Though I'm not a fanboi since I also generally take into account that money is (very) limited entity. If you are in market for tool with particular price/performance ratio, than Apple is definitely not for you. Yet, Apple "Just Works" with much higher probability than M$ or Linux powered systems. (Though with some vendors' systems Linux too reached the point of "Just Works".)
2. It happens all the time to Microsoft. Mostly because of their archaic, backward APIs they never really even attempt to clean up or provide clean way to access particular functionality. As Microsoft vs. fanbois case goes, it's more like everybody hates to be the slave of the M$ release strategy. And hey, I'd love to "murder" M$ too, since I'm dealing with the crap on daily basis.
Since M$ always sees the end-users of Windows only as a number on an accounting sheet, there are no true M$ fanbois (only people who forced themselves to like it because they have no choice). So obviously fanboism-wise there is a bias toward Apple (which sometimes actually listens to the unfiltered feedback from its users).
This is not a first Apple's blopper. Any OS vendor might have those.
The question is how long would it take for Apple to fix that. In the blog post linked Fedora Perl issues actually took about year to deliver fix for RHEL.
While compiling and using your own build of Perl (or using Fink) on Mac OS X is absolutely OK, under RHEL that might easily screw up your RH support contract...
What I don't want to do is become a manager.
Company can't without management. This is a fact.
If you want to have a stand against management intervention, your only choice is to be on the same level as they are... I've being in the situations like that before - with no positive experience to share.
What management tries to accomplish is generally well intended. If one team profits greatly from some tool - they'd try to make the tool available to other teams. Essentially, as your tool grows in its importance to company, so must you. This is also a good promotion chance (e.g. to get "Sr." or "Principal" or "Key" prefix to your actual position name).
One shouldn't forget in the situation old saying: one man's problem - other man's opportunity. But of course to catch the opportunity you have to understand well why management is getting involved. It's really worth asking: management when on some agenda generally very talkative.
I'd hate it. I'd be much less productive.
This is very old stereo-type. You just have to learn instead of lines of code to manage people. Imagine that you have not one but two pairs of hands? And how much more could you do with twice more hands? Yep, that's what management ideally is.
There must be companies that recognize what a good engineer is worth, but I've yet to see one that paid them more than management.
Some really talented engineers might have higher salaries than management. I have seen it. Once.
Low/middle tier managers are the people who are responsible for executing business plan of the company. Upper management - and their vision for product development, business plan - is what creates work for engineers. The company as a whole what makes of faceless technology/tool a product others want to fork money for. And the money - are the wages.
Consequently engineers generally do not influence directly the profits, thus they have lower wages when compared to management. (And unlike old "chicken or the egg problem", here it is clear: management is first, because they have created from ground zero a company.)
You are in a way right. Yet you are wrong.
Talk is air. Work is what drives innovation.
There are countless - failed - products around. Failed solely because people who did them didn't bothered to communicate with customers, releasing essentially gimmick nobody needs.
Healthy discussions with customers about shortcomings of a product, followed by inside discussions on why product ended up released in that way. That's how companies survive in long term: by making something others want to buy.
This entire discussion is a sign of poor hiring by the company involved. If they want innovative people they should hire innovative people. It isn't that hard - look for people who have done innovative things in the past and pay them money to work for you.
That's just plain stupid.
Sorry for the oxymoron, but all people are born innovative. True managerial talent is to get the innovative nature out of people for good of business.
General problem with hiring "innovative people" is that most of them can't keep on the same piece of work for very long time. Innovation is matter of a short moments. End product - is thousands person/days of many many employees. Few truly innovative people can stick to the business routine. And very few companies go to compromise and provide innovative people with sort of isolated environment - where they are isolated from usual business routine related to making of a product.
The rest is just common sense: give them the responsibility and resources to achieve change, think twice before screwing them over, and expand the scope of their resources (personal or departmental) as they deliver results.
That's common sense. Yet your base off by far.
Responsibilities is what used to keep people in check. Yet, not much people are capable of bearing responsibilities. If one can - then they'd likely to choose managerial career. That means rest of "innovative" bunch is precisely the people who can't manage, can't cope with responsibilities and rarely can work under pressure. In other words - rest of us, employees.
That's why proper communication with employees is needed. General problem that many managers can't cope with critique of their decisions. Eventually any kind of critique falls under unwritten ban leading to dried up communication within company.
Oh lets fire the janitor because his suggestion on how to improve productivity has failed.
Corrected version:
Oh lets fire the janitor because his suggestion I have plagiarized on how to improve productivity has succeeded.
And I personally think that giving away bonuses would only increase tension and discrimination inside of teams.
I prefer simpler idea suggested above: permit to criticize management and their decisions. Ban on criticism is essentially what most often leads to disappearance of discussions. Healthy discussion is what drives innovation.
GPUs excel at tasks that map N input values to one output value, with a minimum amount of unpredictable branches. If a task fits in this well, it is likely being accelerated already, via CUDA, Stream, CTM. If it doesn't fit, forcing it on the GPU is a waste of time.
I understand your sentiment - as software developer.
Yet, if you look at situation from nVidia pov, all what you say are real disadvantages of GPU compared to CPU. Trying to improve in the areas for nVidia is only logical - to compete better against Intel/AMD. Probably even more against AMD than Intel.
While Intel and PS4 are pretty much wild speculation - based on logic (Intel is specialist in cheap chip production, something Sony urgently needs for its PS3), the nVidia and x86 are based on hirings.
While I will not go as far as to say that nVidia is attempting to implement whole CPU, it could be that they are trying to put CPU emulator/accelerator on to GPU. Scrapping the shader language and allow to write/compile plain C/etc which can be run unmodified on both CPU and GPU is a huge step forward to allow hybrid/partial acceleration, scaling the technology from lowest-end to highest-end.
Both moves have logic behind them. Both are speculations. First was already denied. But let the soap opera run for few more episodes^W the Inquirer articles more.
Style-wise, KDE never hid fact they were using best off Windows design. In past times - KDE 1/2 and GNOME 1 - GNOME was pitched as *nix thing and KDE as something imitating to Windows UI.
What I meant by the comparison is development model. KDE is quite decentralized. Only handful of applications are written by the core KDE team (which has number of people from Qt team). Most applications - most of KDE innovations - they happen outside of core and they are what most users see.
Now in Windows and GNOME part of universe, you would see strong commercial support and consequently centralized management of the projects. MS controls Windows. RH/Suse/Sun control GNOME. The parties control more or less completely what gets included and when new releases happen. (e.g. RH syncs releases of GNOME with releases of Fedora).
That's why KDE folks loosely follow strategy "release more, release often" while GNOME follows strategy "release on schedule; drop features if needed." Needless to point that latter is MS Windows release strategy too.
Ah, thanks for the information! It hadn't even occurred to me that something like this would be configurable. Is there a reason it's disabled by default? It seems the only people who wouldn't want it enabled would be those who don't use keyboard shortcuts, and it wouldn't impact them in any case.
Never ever I had problem under Mac OS X when e.g. cleaning keyboard when computer is still on. Or simply by accident palming half of keyboard.
I wouldn't recommend that on Windows - and especially on Linux. Results might be surprising or (worse) unrecoverable.
I'm still in awe of Apple's genius for making "Enter" key not to open/start selected file/program. (Cmd-O does that in Mac OS X). I had crashed Win95 this way once: pressed Ctrl-A thinking I was in WinWord, but desktop was selected; then pressed quickly "Enter". Windows naturally tried to start all applications with shortcuts on desktop. Logical - yet stupid.
The fact that in all MS programs you can never resize those popups with too-wide info [...]
I'm not sure what you talking about. Care to provide example? It is actually bothering me as well because now even KDE and GNOME started inhibiting windows resizing.
All I can say that you can try "high contrast" settings. I can attest that all MS produced Windows programs are working perfectly fine under the rather unusual settings. Also, "large fonts" option was always supported by MS applications perfectly. (Now it has different name - lazy to search).
On 3rd party application front this is ... different. Expect various breakages and crashes when using "high contrast" and/or "large fonts". Having been in Windows developer shoes for 5+ years, properly guessing actually activated accessibility options was very fine art. Carefully selecting used graphics functions - as to make application capable of running in the modes - was more of a torture than work.