Perl 5 development is stagnant for one simple reason: Perl 5 is near perfect, there is nothing left to be developed there.
Some wanted better Perl with more consistent syntax. That's what Perl 6 is for. 5.10/etc are intermediate releases serving the purpose of facilitating future migration to Perl 6: some ambiguous constructs of previous version are gone in 5.10/etc.
I personally do not care much about 6th - I yet to find any pathological problem in Perl 5 which would persuade me somehow to move to next big thing. Perl 5 is well documented, has piles of modules and examples all over the net. I see no point to move from it.
... PSP Go is intended to co-exist alongside the other, older PSP with UMD support.
The question is wouldn't publishers simply decide to drop publishing on UMD?
After all it's a proprietary console and game publishers have to pay for everything. At least theoretically, for publishers it's cheaper to make UMD-less game and (again theoretically) profits are higher since you do not have S/H market and (for now) lower piracy.
Right now Sony has no reasons to cancel PSP.
But if publishers would start releasing more and more UMD-less games then Sony though unlike to cancel PSP, surely would make PSP2 UMD-less.
I hate to give the example, but nothing better comes to my mind.
Check out the Japanese anime. You would find that lots of them are similar - yet all of them are different. There are piles and piles of good stories - and interesting worlds with intriguing characters.
Why the hell Nintendo (and people like you) can't get over the Mushroom Kingdom/etc is beyond me. It's not like there was a shortage of good writers there.
Right now Nintento franchises - pretty much all of them - look like a continuation of an endless soap opera with the same setting, same characters and same story. Worst part for gamers: same game play. Yes, they revive fond memories of childhood. No, I want more new memories: I do not like to be stuck at the same place and same time forever.
I just don't understand why a company would expend those kinds of resources to do something that provides nobody with a positive benefit.
Nintendo sells SDK to publishers. Publishers might get pissed that they fork money to Nintendo over something that anybody can get off the net for free.
I haven't heard any other remotely justifiable reason.
Nintendo really needs to reallocate some of the resources they're spending trying to stop people from modding their system into investing in good games.
Well, they haven't yes made a single game with e.g. "Hyper" prefix. Rest was already sequelled, hashed, resequelled and rehased countless times to death.
Some people (me including) question whether Nintendo is capable of coming with something at all. WiiSport* seem to be an exception - Nintendo hadn't expected it to succeed at all. So they do not know what to do with the new accidentally acquired audience nor with piles of money they earned unexpectedly.
Why couple of guys can write in months commercial grade H.264 decoder which needs 1GHz CPU for 720p content - and the whole bunch of developers working on VLC/ffmpeg/libavc/etc can't?
... I'm really annoyed that health care is currently distracting the Senate...
Look at bigger picture. Do not be narrow minded as rest of the scientists.
Climate change first and foremost affects humans. Having better health care would help to absorb some of the climate change effects.
One step at a time. There is always time for the panic and apocalypse. At the moment we try to make sure that humanity as it is now would survive. And that we would be able to live on *after* surviving.
No. On Mac OS X best shot is the the MPlayer OSX Extended. At H.264 playback it's better than vanilla CCCP, but not as good as commercial CoreAVC.
VLC sadly is as hopeless as it was before. When I heard that they finally supported ASS subtitles I was excited to try it out - only to find that it still sucks at any contemporary media job.
The point is that banning a symbol doesn't change people. And symbol gets its meaning from people. It only suppresses expression of their true wishes. They'd find another symbol - and another scapegoat to blame for their problems - as soon as they would accumulate enough negative emotions.
What actually happened is that svastika's relation to Hitler and nazis was as good as perpetuated by the ban. IOW, you can't get over the problem by forcing yourself to stop thinking about. That simply doesn't work.
Germany would have more success parting svastika from its past by doing reverse: paint svastikas with flowers and funny colors and and slap them all over the country.
Make people smile at it - not shun it. Suppression doesn't work - reframing does.
Bavaria was btw one of the least nazist lands probably. They are simply over-conservative so even smallest strain of nazism is going to remain there for quite some time. (Hint: nazism came to power and spread from poor German lands while Bavaria was (and is) one of the richest.)
Frankly the ban on svastika is absurd, considering that neo-nazis are pretty harmless bunch and it is anti-nazis whom I actually afraid of more.
In northern poor lands of Germany (where from browns have originated) though spirit of racism is still kicking. Names or symbols do not matter IMO. But Germany instead of solving the racism problem concentrates too much on apologetic measures like this ban.
What you say might be regarded as valid - until you recall BSD.
The point of BSD that it is a kernel + system libraries + system tools + more.
Dropping the "more" part, you actually come to a sane kernel development model.
To understand that in full, try to make primitive binary distro. I did that once for embedded project and let me tell you that experience was that great, that in the end we decided to increase flash size and use stripped down Debian. Because with Linux one needs a shitload of *3rd* *party* mini tool and libraries required to manage kernel resources and access hardware capabilities. The point being that's one hell of [*CENSORED*] job putting together usable Linux system.
With BSD the problem simply doesn't exist. Nor application developers have to scratch their backs which of the dozens 3rd party tools and wrapper libraries to use: if there is a standard system library for the purpose, they simply pick it. And in BSD there is a library to access any of provided functions.
Simple fact that Linux is only a kernel - and Linus/etc refuse to bundle anything else - greatly contributes to the chaotic state of the Linux application eco-system. They believe that distros can manage that simply harms everybody in long term.
In past my simple solution was to go with whatever Debian ships. Not universal nor freshest. But in my experience the best what Linux eco-system ever produced.
Why should Linus focus for Desktop Linux. It is a dead horse...
And in some part is a dead horse thank to Linus himself.
Point is that "perfect kernel" from system developer POV, is "piece of useless junk" from POV of application developers.
Sound interface is at best dysfunctional. Video acceleration is constantly "under construction" (redone 5th time now or so). Real-time timers required for smooth multimedia and games are still at large.
Just look at Apple's Mac OS X on how problems have to be handled. Instead of debating about what should/shouldn't be in "perfect kernel," people concentrate their work on areas which actually relevant to application developers and of benefit to end users. Apple took the line "if we don't do it who else" while Linus' official line is something like "do it in userspace" or "do not care. don't have to. I'm system programmer."
Just look at Apple (Steve Jobs) or MS (Bill Gates) or Oracle (Larry Ellison) or Ubuntu (Mark Shuttleworth) or Enlightenment (Rasterman) to realize why leadership could be even more important than code contribution.
Embedded folks traditionally use branched off releases.
Budget of most embedded project rarely has room for migration and retest of newer kernel/OS version. For new hardware revision may be, otherwise - use the same old stuff which worked before.
Stability and costs are top priorities there. Nobody's changing anything just for sake of changing something.
Finally to the point: Linux and embedded developers are quite loosely coupled. It's OK to forget about them (what most Linux developers indirectly paid by Oracle do all the time anyway). Mainline Linux itself is hardly ever used and patchsets from embedded vendors are norm.
The main reason why Linux is used in embedded space is the GPL. Even 7 years ago it was literally impossible to find an embedded OS without per-unit licensing costs. Since then Linux literally turned the market up side down.
I wonder how much of this problem can be traced to the original design philosophy regarding kernel size. There was a famous argument about whether or not a microkernal is superior. Well, it certainly is superior in one way: it is very bloat-resistant!
Micro-kernels are feature-resistant too.
Bloat in best case (when people watch out for it) is an intermediate state of a project which swallowed lots of new code. This is normal and happens all the time.
In well managed projects bloat gets assimilated into the rest of the project pretty quickly - during maintenance process.
Meanwhile, when you decide to add various appliances to a kernel, what is going to keep the kitchen sink from being added, too? That is, where do you draw the line, between what should be part of a kernel and what should merely be just another application?
I personally do not like to draw the lines in such cases. Rejecting a feature IMO is often a missed opportunity. It's better to take the feature in and play with it around. Dropping useless or misplaced feature later is always easy.
And even if the feature gets removed, one at least gets better idea what and why people want from your project. That always helps further development of project.
Drawing a hard line - refusing stuff on principal grounds - causes only stress on both sides, nothing more.
But I'm of course speaking about "good" features, which relate directly to the project. Quite often people make a buzz about problem in one place, but try to solve it quickly in other place. That I do reject immediately without second thought.
The developer who has all the talent in the world, but lacks either motivation or drive to perform up to expectations. As a manager, I expect to be able to motivate team members with money, career advancement, cool projects or even intangibles such as increased work schedule flexibility.
LOL. This is a classical B.S. Yes, often direct (line) managers wants to motivate developers. But it still has to be approved by higher management. And this is where it goes terribly wrong.
It either takes ages to see results or something unasked and unwanted gets done. Or worse: it gets done, but then used to motivate somebody else.
But sometimes, the rewards just donâ(TM)t motivate.
The result is a developer who isnâ(TM)t accountable. They consistently are late to work and meetings. They donâ(TM)t adhere to standards. Theyâ(TM)re simply complacent.
Yep. That's me. E.g. i was dragged into three weeks of meeting about architectural problem I discovered - and I had to open every one of them by asking what the meeting is about and tens time repeating them that I have solved the problem week(s) ago. But the wheels just can't stop... They finally found something worth discussing and simply can't pass on the chance.
Remind me again how that supposed to motivate me?
Or performance reviews. They keep asking what I might be interesting working in future. And the whole list of things I'm interested in gets consistently shot down with "we do not do that" or "C*O will not approve." Also very motivating. Even trivial things gets shot down - because most managers are afraid to do anything on their own and have to get a nod from above for every minor thing. And obviously all the trivial things are too small to be discussed with higher management.
The problem is when the developer gets too lazy or too cocky and starts pushing their deliverables to the last minute, causing delays.
Oh come on!!! Are you playing idiot here??
Tried and true solution: move deadline few days/weeks back. Or if you are more advanced, learn to manage projects better and teach people to work on "mini" dead-lines by splitting one huge deliverable into smaller project phases.
Or they just aren't around when other developers need to talk to them. Eventually the ax will come down on them as well â" the manager must look out for what is best for the team and long term success of the organization.
You really being too long in management. And probably got used to your position "above the mere mortals."
If you want to become good manager, start learning how life goes. E.g. take psychology classes. Because developers are people too - they can't live in office vacuum forever. They need more *new* information. They need more diversity. Especially talented developers, as their brains burn them from inside, need even greater amount of information and diversity just to keep their brain from eating them from inside. Yet traditionally managers, to accommodate mediocre ones, filter information. Because mediocre ones get confused with too much information. But talented ones need the info to be "in touch" with work and results of the work.
Another advise I was giving some managers is to make internal mini projects to simply keep creative and talented developers busy. That was derived from my personal experience working with extremely talented manager.
In other words, there are tons of ways to lead people or at least to make them think you are leading them. For few exceptional people you might want to follow them or make them feel that you follow them. But few managers even consider getting acquainted with their subordinates. They'd rather wait people start going crazy.
Slashdot Mirror
Uhm...
Perl 5 development is stagnant for one simple reason: Perl 5 is near perfect, there is nothing left to be developed there.
Some wanted better Perl with more consistent syntax. That's what Perl 6 is for. 5.10/etc are intermediate releases serving the purpose of facilitating future migration to Perl 6: some ambiguous constructs of previous version are gone in 5.10/etc.
I personally do not care much about 6th - I yet to find any pathological problem in Perl 5 which would persuade me somehow to move to next big thing. Perl 5 is well documented, has piles of modules and examples all over the net. I see no point to move from it.
They are part of RIAA and they are their official position. Google for it.
Having your purse stolen during festival or rectal colonoscopy in U.S. airport. What would you pick?
how awesome a Brazillian opening and closing ceremony will be,
Rest of the world would never know about it - because it would be rated 18+/21+ and would never be aired.
The question is wouldn't publishers simply decide to drop publishing on UMD?
After all it's a proprietary console and game publishers have to pay for everything. At least theoretically, for publishers it's cheaper to make UMD-less game and (again theoretically) profits are higher since you do not have S/H market and (for now) lower piracy.
Right now Sony has no reasons to cancel PSP.
But if publishers would start releasing more and more UMD-less games then Sony though unlike to cancel PSP, surely would make PSP2 UMD-less.
I assume the PSP Go is DOA!
But. If you include the bad influence of "Sony" brand, then it is clear that it is the PSP is EOL.
It's Sony we are talking about. *SONY*.
I hate to give the example, but nothing better comes to my mind.
Check out the Japanese anime. You would find that lots of them are similar - yet all of them are different. There are piles and piles of good stories - and interesting worlds with intriguing characters.
Why the hell Nintendo (and people like you) can't get over the Mushroom Kingdom/etc is beyond me. It's not like there was a shortage of good writers there.
Right now Nintento franchises - pretty much all of them - look like a continuation of an endless soap opera with the same setting, same characters and same story. Worst part for gamers: same game play. Yes, they revive fond memories of childhood. No, I want more new memories: I do not like to be stuck at the same place and same time forever.
I just don't understand why a company would expend those kinds of resources to do something that provides nobody with a positive benefit.
Nintendo sells SDK to publishers. Publishers might get pissed that they fork money to Nintendo over something that anybody can get off the net for free.
I haven't heard any other remotely justifiable reason.
Nintendo really needs to reallocate some of the resources they're spending trying to stop people from modding their system into investing in good games.
Well, they haven't yes made a single game with e.g. "Hyper" prefix. Rest was already sequelled, hashed, resequelled and rehased countless times to death.
Some people (me including) question whether Nintendo is capable of coming with something at all. WiiSport* seem to be an exception - Nintendo hadn't expected it to succeed at all. So they do not know what to do with the new accidentally acquired audience nor with piles of money they earned unexpectedly.
Yes. It's pathetic.
Why couple of guys can write in months commercial grade H.264 decoder which needs 1GHz CPU for 720p content - and the whole bunch of developers working on VLC/ffmpeg/libavc/etc can't?
Look at bigger picture. Do not be narrow minded as rest of the scientists.
Climate change first and foremost affects humans. Having better health care would help to absorb some of the climate change effects.
One step at a time. There is always time for the panic and apocalypse. At the moment we try to make sure that humanity as it is now would survive. And that we would be able to live on *after* surviving.
Anyway, whether it is human activity or not, weather is messed up big time.
What planet you are from again?
No. On Mac OS X best shot is the the MPlayer OSX Extended. At H.264 playback it's better than vanilla CCCP, but not as good as commercial CoreAVC.
VLC sadly is as hopeless as it was before. When I heard that they finally supported ASS subtitles I was excited to try it out - only to find that it still sucks at any contemporary media job.
SMPlayer makes sure that you never ever need to see command line.
On Linux and Mac OS X (where MPC + CoreAVC isn't available), Mplayer front-ends are your surest bet for HD video playback with soft subtitles.
As much as I wish for VLC to work, it is probably worst of all HD capable players, having all possible problems: subs sync, a/v sync, video jitter.
CCCP
Anime went MKV way (x264+Vorbis) for HD release quite some time ago.
Also I hear recent DivX supports MKV files too.
Symbols do empower.
Rituals too.
The point is that banning a symbol doesn't change people. And symbol gets its meaning from people. It only suppresses expression of their true wishes. They'd find another symbol - and another scapegoat to blame for their problems - as soon as they would accumulate enough negative emotions.
What actually happened is that svastika's relation to Hitler and nazis was as good as perpetuated by the ban. IOW, you can't get over the problem by forcing yourself to stop thinking about. That simply doesn't work.
Germany would have more success parting svastika from its past by doing reverse: paint svastikas with flowers and funny colors and and slap them all over the country.
Make people smile at it - not shun it. Suppression doesn't work - reframing does.
Bavaria was btw one of the least nazist lands probably. They are simply over-conservative so even smallest strain of nazism is going to remain there for quite some time. (Hint: nazism came to power and spread from poor German lands while Bavaria was (and is) one of the richest.)
Frankly the ban on svastika is absurd, considering that neo-nazis are pretty harmless bunch and it is anti-nazis whom I actually afraid of more.
In northern poor lands of Germany (where from browns have originated) though spirit of racism is still kicking. Names or symbols do not matter IMO. But Germany instead of solving the racism problem concentrates too much on apologetic measures like this ban.
What you say might be regarded as valid - until you recall BSD.
The point of BSD that it is a kernel + system libraries + system tools + more.
Dropping the "more" part, you actually come to a sane kernel development model.
To understand that in full, try to make primitive binary distro. I did that once for embedded project and let me tell you that experience was that great, that in the end we decided to increase flash size and use stripped down Debian. Because with Linux one needs a shitload of *3rd* *party* mini tool and libraries required to manage kernel resources and access hardware capabilities. The point being that's one hell of [*CENSORED*] job putting together usable Linux system.
With BSD the problem simply doesn't exist. Nor application developers have to scratch their backs which of the dozens 3rd party tools and wrapper libraries to use: if there is a standard system library for the purpose, they simply pick it. And in BSD there is a library to access any of provided functions.
Simple fact that Linux is only a kernel - and Linus/etc refuse to bundle anything else - greatly contributes to the chaotic state of the Linux application eco-system. They believe that distros can manage that simply harms everybody in long term.
In past my simple solution was to go with whatever Debian ships. Not universal nor freshest. But in my experience the best what Linux eco-system ever produced.
Why should Linus focus for Desktop Linux. It is a dead horse...
And in some part is a dead horse thank to Linus himself.
Point is that "perfect kernel" from system developer POV, is "piece of useless junk" from POV of application developers.
Sound interface is at best dysfunctional. Video acceleration is constantly "under construction" (redone 5th time now or so). Real-time timers required for smooth multimedia and games are still at large.
Just look at Apple's Mac OS X on how problems have to be handled. Instead of debating about what should/shouldn't be in "perfect kernel," people concentrate their work on areas which actually relevant to application developers and of benefit to end users. Apple took the line "if we don't do it who else" while Linus' official line is something like "do it in userspace" or "do not care. don't have to. I'm system programmer."
And it's not like it is all rosy on Linux side.
Not once I had to upgrade half of OS just to be able to use some new application.
Leadership is also contribution.
Just look at Apple (Steve Jobs) or MS (Bill Gates) or Oracle (Larry Ellison) or Ubuntu (Mark Shuttleworth) or Enlightenment (Rasterman) to realize why leadership could be even more important than code contribution.
Embedded folks traditionally use branched off releases.
Budget of most embedded project rarely has room for migration and retest of newer kernel/OS version. For new hardware revision may be, otherwise - use the same old stuff which worked before.
Stability and costs are top priorities there. Nobody's changing anything just for sake of changing something.
Finally to the point: Linux and embedded developers are quite loosely coupled. It's OK to forget about them (what most Linux developers indirectly paid by Oracle do all the time anyway). Mainline Linux itself is hardly ever used and patchsets from embedded vendors are norm.
The main reason why Linux is used in embedded space is the GPL. Even 7 years ago it was literally impossible to find an embedded OS without per-unit licensing costs. Since then Linux literally turned the market up side down.
I wonder how much of this problem can be traced to the original design philosophy regarding kernel size. There was a famous argument about whether or not a microkernal is superior. Well, it certainly is superior in one way: it is very bloat-resistant!
Micro-kernels are feature-resistant too.
Bloat in best case (when people watch out for it) is an intermediate state of a project which swallowed lots of new code. This is normal and happens all the time.
In well managed projects bloat gets assimilated into the rest of the project pretty quickly - during maintenance process.
Meanwhile, when you decide to add various appliances to a kernel, what is going to keep the kitchen sink from being added, too? That is, where do you draw the line, between what should be part of a kernel and what should merely be just another application?
I personally do not like to draw the lines in such cases. Rejecting a feature IMO is often a missed opportunity. It's better to take the feature in and play with it around. Dropping useless or misplaced feature later is always easy.
And even if the feature gets removed, one at least gets better idea what and why people want from your project. That always helps further development of project.
Drawing a hard line - refusing stuff on principal grounds - causes only stress on both sides, nothing more.
But I'm of course speaking about "good" features, which relate directly to the project. Quite often people make a buzz about problem in one place, but try to solve it quickly in other place. That I do reject immediately without second thought.
The developer who has all the talent in the world, but lacks either motivation or drive to perform up to expectations. As a manager, I expect to be able to motivate team members with money, career advancement, cool projects or even intangibles such as increased work schedule flexibility.
LOL. This is a classical B.S. Yes, often direct (line) managers wants to motivate developers. But it still has to be approved by higher management. And this is where it goes terribly wrong.
It either takes ages to see results or something unasked and unwanted gets done. Or worse: it gets done, but then used to motivate somebody else.
But sometimes, the rewards just donâ(TM)t motivate.
The result is a developer who isnâ(TM)t accountable. They consistently are late to work and meetings. They donâ(TM)t adhere to standards. Theyâ(TM)re simply complacent.
Yep. That's me. E.g. i was dragged into three weeks of meeting about architectural problem I discovered - and I had to open every one of them by asking what the meeting is about and tens time repeating them that I have solved the problem week(s) ago. But the wheels just can't stop... They finally found something worth discussing and simply can't pass on the chance.
Remind me again how that supposed to motivate me?
Or performance reviews. They keep asking what I might be interesting working in future. And the whole list of things I'm interested in gets consistently shot down with "we do not do that" or "C*O will not approve." Also very motivating. Even trivial things gets shot down - because most managers are afraid to do anything on their own and have to get a nod from above for every minor thing. And obviously all the trivial things are too small to be discussed with higher management.
The problem is when the developer gets too lazy or too cocky and starts pushing their deliverables to the last minute, causing delays.
Oh come on!!! Are you playing idiot here??
Tried and true solution: move deadline few days/weeks back. Or if you are more advanced, learn to manage projects better and teach people to work on "mini" dead-lines by splitting one huge deliverable into smaller project phases.
Or they just aren't around when other developers need to talk to them. Eventually the ax will come down on them as well â" the manager must look out for what is best for the team and long term success of the organization.
You really being too long in management. And probably got used to your position "above the mere mortals."
If you want to become good manager, start learning how life goes. E.g. take psychology classes. Because developers are people too - they can't live in office vacuum forever. They need more *new* information. They need more diversity. Especially talented developers, as their brains burn them from inside, need even greater amount of information and diversity just to keep their brain from eating them from inside. Yet traditionally managers, to accommodate mediocre ones, filter information. Because mediocre ones get confused with too much information. But talented ones need the info to be "in touch" with work and results of the work.
Another advise I was giving some managers is to make internal mini projects to simply keep creative and talented developers busy. That was derived from my personal experience working with extremely talented manager.
In other words, there are tons of ways to lead people or at least to make them think you are leading them. For few exceptional people you might want to follow them or make them feel that you follow them. But few managers even consider getting acquainted with their subordinates. They'd rather wait people start going crazy.
SunFire vs. blade? Quite unfair comparison.