Weekly Edition
Return to the Front page
| |||||||||||||
The Grumpy Editor's guide to 2009
Author Charles Stross recently lamented
that times have gotten sufficiently interesting that the writing of
near-future science fiction is currently impossible. Too much is changing,
in too many interesting and unpredictable ways, for anybody to make
projections of the future that don't look ridiculous long before that
future arrives. Your editor can certainly understand that concern. But,
then, your editor's predictions have always looked ridiculous in
short order. So there's no reason not to continue with business as usual.
Here's a set of wild guesses as to what we might see this year. Woe
unto anybody who takes any of this seriously.
CommercialThe net is full of guesses about what the currently-unfolding financial crisis will mean for free software; many of those are wildly optimistic. Your editor is a bit more guarded: the free software community will emerge from this mess stronger than ever, but it may well be a difficult ride. Much of the commercial Linux industry draws a fair amount of its income from the financial industry, and many players in that industry - there should still be one or two left - are likely to be looking to cut their expenses somewhat. So money for little things like critical infrastructure may be a little short until the bonus pool can be brought back to a satisfactory level. Other parts of the economy will be suffering similar pain. All told, economic trouble will make life harder for a number of free software companies - and the people they employ. Still, the lower cost of free software, along with its flexibility, can only serve to make it more appealing to companies which are trying to develop a successful business strategy for difficult times. The commercial ecosystem around free software should continue to grow, but it may go through some interesting changes along the way. One thing that will help is that open embedded systems will grow in appeal and become more successful. The iPhone showed what can be done with an interesting hardware platform; at the same time, it has spawned a steady industry devoted to opening up the device. Android-based platforms are quickly showing that it's possible to make an equally (or almost equally) nice device without locking it down in the same way. Awareness of the value of open gadgets will grow, and there will be more of them on the market by the end of 2009. These gadgets may not be as completely open as many LWN readers would like, but they will be a big step in the right direction. As that happens, your editor thinks that Android will grow in popularity, perhaps to the point where it eclipses other Linux-based handset platforms. Android has no shortage of flaws, but it is a sufficiently well thought-out and developed system that it should be able to attract a real development community - especially if Google opens up its processes sufficiently. And if Google maintains an overly-firm hand on Android, we may well see forked versions aimed at the hardware devices which can run them.
LegalThe pace of GPL enforcement actions will drop as a result of two independent developments: more companies will figure out that free software licensing matters, and developers will decide that they do not want to be part of a high-profile lawsuit. That said, there will be some significant actions on this front in 2009. Meanwhile, the FSF's GPL-infringement lawsuit against Cisco will be settled in a flurry of "win-win" press releases. GPLv3 migrations will slow, especially among projects that people have actually heard of. A formerly friendly company may pull an SCO. The sad fact is that failing companies have a certain tendency to look toward their "IP portfolio" as a last-ditch source of revenue. 2009 is likely to see more than the usual number of failing companies; do not be surprised if one of them grasps at this particular straw.
DistributionsDebian Lenny will be released. Now that the ritual firmware flame war and general resolution obligations have been satisfied, it looks like even Debian would be hard put to not get a release out this year. Debian will also make a serious attempt to avoid a repeat of the recent general resolution mess. There will be changes to how resolutions find their way to a vote, and the scripture-like authority of the "foundation documents" may be eroded somewhat. We still won't know about Fedora's "infrastructure issues". But they'll promise to fill us in as soon as they possibly can. In the mean time, Fedora will crank out two more solid releases, one of which will eventually show up (somewhat transformed) as the next RHEL release. openSUSE will make it easier for outside developers to maintain packages in an attempt to bolster its relevance in the development community.
DevelopmentThe 2.6.33 kernel will be released. In other words, the kernel development cycle will continue at its fast pace, and the numbering scheme will not be changed. The realtime patch set will be mostly merged by the end of the year. It really has to happen this time. What could possibly go wrong? After many years of effort, 3D graphics will be a solved problem on Linux systems. We will no longer be second to other systems with regard to functionality or performance - at least, if you buy your video hardware from cooperative companies. Some of the code may still be working its way through the distribution system, but the work will be done. It will be a make-or-break year for Perl. If the Perl developers cannot either bring new life to Perl 5 or turn Perl 6 into something real, this language will, by the end of the year, have moved well down the road to "legacy" status. By the end of the year, KDE 4 will have stabilized, and most users will have forgotten what all of the flames were about. Meanwhile, the first pieces of GNOME 3 may be out, but they are likely to be received without great enthusiasm. The distributed version control system debates will continue in full force through the year. A number of major projects will make the jump to a DVCS, and most of them will go to git. But Mercurial and Bzr (at least) will remain strong contenders. As a result of declining contributions from Sun and frustration felt by outside developers, OpenOffice.org will be forked. The new project is likely to have some initial troubles - OpenOffice.org is a big program - but it will eventually become the focus of a much more dynamic, community-oriented system.
ConclusionThis article would not be complete without a prediction that free software will be stronger than ever at the end of 2009. Some predictions are easy to make; that has been the trend for many years, after all. Still, it is going to be interesting to see what we will be able to accomplish over the next twelve months. As always, it is going to be fun. Finally, it will be a hard year for Linux-related media; we have already seen a foreshadowing of the situation with Groklaw's shift into maintenance mode and the recent demises of LinuxWorld.com and Linux.com. It is a hard time to be in the media business in general, and the free software realm offers challenges of its own even in the best of times. That said, LWN appears to be holding steady so far, thanks to thousands of readers who feel that this enterprise is worth supporting. So your editor is able to confidently predict that we'll still be here for the traditional mocking of these predictions in December. (Log in to post comments)
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 2:33 UTC (Thu) by pr1268 (subscriber, #24648) [Link] If some other company "pulls a SCO", then Groklaw will likely need to come out of maintenance mode to cover it. ;) While I'm not a Perl apologist, I just can't see it ever becoming "legacy". Or, if one considers it to be legacy already, then it'll join the ranks of FORTRAN and COBOL and such as one of those ancient languages that demands a lot of skilled programmers in perpetuity. 2.6.33 sounds mighty optimistic, given how the time interval between 3-number kernel releases continues to grow. We'll see... We still won't know about Fedora's "infrastructure issues". But they'll promise to fill us in as soon as they possibly can. I'm not holding my breath. Forgive me if I sound trollish, but I'm resigned to thinking that Fedora will quietly let sleeping dogs lie on this one (for legal reasons). Finally, it will be a hard year for Linux-related media; we have already seen a foreshadowing of the situation with Groklaw's shift into maintenance mode and the recent demises of LinuxWorld.com and Linux.com. Please, don't let LWN suffer the same fate as these! Thanks to LWN's editors for all the fine work. Here's to a fun and productive 2009!
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 4:40 UTC (Thu) by jordanb (guest, #45668) [Link]
> While I'm not a Perl apologist, I just can't see it ever
> becoming "legacy". Or, if one considers it to be legacy > already, then it'll join the ranks of FORTRAN and COBOL > and such as one of those ancient languages that demands > a lot of skilled programmers in perpetuity.
One thing that potentially makes Perl different than Fortran and COBOL is that the latter two survive and prosper (in their own way) by serving a particular niche very well.
To the extent that Perl has a niche it's being plowed into by other languages (Python for system scripting, and a grab bag of them for web scripting). To look at the lifecycle of a language that is attacked in its niche, it might do well to look at something like Pascal. Yes, there still is some Pascal/Delphi work being done in this industry, but it's highly anemic. There's just no sector anymore where Pascal is still the 'default' choice for doing anything.
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 7:26 UTC (Thu) by tajyrink (subscriber, #2750) [Link]
I'd guess the kernel version was somewhat of a typo. 2.6.29 03/09, 2.6.30 06/09, 2.6.31 09/09, 2.6.32 12/09 would seem something the guess for (and might be missed), but 2.6.33 during this year is quite improbable.
Small grammar fix? Posted Jan 8, 2009 8:20 UTC (Thu) by mlawren (subscriber, #10136) [Link]
"pulls a SCO" - you wrote it that way, but didn't mention that the article has written it as "pulls an SCO" which doesn't read right, to my eyes.
Small grammar fix? Posted Jan 8, 2009 13:43 UTC (Thu) by roblucid (subscriber, #48964) [Link]
> "pulls a SCO" - you wrote it that way, but didn't mention that the article > has written it as "pulls an SCO" which doesn't read right, to my eyes.
If I say "skow" to rhyme with then it's "pulls a SCO", but if I say ess-see-oh, then it's "pulls an SCO". What reads right, might depend on how you pronounce the acronym.
Small grammar fix? Posted Jan 8, 2009 13:44 UTC (Thu) by roblucid (subscriber, #48964) [Link]
s/"skow" to rhyme with/& slow/p
Small grammar fix? Posted Jan 8, 2009 14:22 UTC (Thu) by hummassa (subscriber, #307) [Link]
"pulls _an_ ess-cee-oh" reads OK to me :-)
Small grammar fix? Posted Jan 8, 2009 14:31 UTC (Thu) by pr1268 (subscriber, #24648) [Link] "pulls a SCO" - you wrote it that way, but didn't mention that the article has written it as "pulls an SCO" which doesn't read right, to my eyes. I habitually pronounce SCO as a single-syllable word that rhymes with "snow" or "slow". It is an acronym, so saying it as "S-C-O" wouldn't be improper. I perish the thought of our editor agonizing over whether to use "a" or "an" in that sentence. :)
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 8:28 UTC (Thu) by Ze (guest, #54182) [Link] I'm not holding my breath. Forgive me if I sound trollish, but I'm resigned to thinking that Fedora will quietly let sleeping dogs lie on this one (for legal reasons). What legal reasons? Honestly I reckon Fedora will try to sweep it under the carpet so they aren't further embarrassed. Now I'm going to take a completely uninformed wild guess and say the compromise was most likely due to incompetence in securing their own servers ,perhaps even someone not following the projects procedures for security. Sweeping it under the carpet is what they shouldn't do , as anybody who cares about security should be assuming the worst possibilities rather than ignoring it.Until you know what happened you can't know if the procedures in place are sufficient to fix further problems or even fix the current problem.
The Grumpy Editor's guide to 2009 Posted Jan 15, 2009 10:23 UTC (Thu) by renox (subscriber, #23785) [Link]
[[While I'm not a Perl apologist, I just can't see it ever becoming "legacy".]]
I consider that there's two Perl language: Perl5 which is 'legacy'/'stable' as it won't change much now and Perl6 which is very different from Perl5.
Perl6 as a new language will have to compete against Python3, Ruby and Perl5, so I wouldn't bet on it..
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 2:38 UTC (Thu) by miguelzinho (subscriber, #40535) [Link]
Who would be crazy to fork OpenOffice?
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 4:33 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
To a large extend, Openoffice.org as included within distributions have deviated quite a bit based on http://go-oo.org/. While it may not be formally a fork, it essentially can be considered one. There is also OxygenOffice, NeoOffice as community forks and IBM Lotus Symphony, based on OO.o as well.
The Grumpy Editor's guide to 2009 Posted Jan 10, 2009 17:06 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]
I just hope some company with serious resources will realize the OO.o
codebase is a dead end, rewriting it is a waste of time and there is a better solution out there: KOffice. Sure, they don't have the features, but they DO have the infrastructure to surpass OO.o within a very short time, given the resources.
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 4:20 UTC (Thu) by vmlinuz (guest, #24) [Link] It is a hard time to be in the media business in general, and the free software realm offers challenges of its own even in the best of times. That said, LWN appears to be holding steady so far, thanks to thousands of readers who feel that this enterprise is worth supporting. Thanks for the reminder! I've just upped my sub from 'starving hacker' - because I was one last year and I'm not now - and renewed for a year. Keep up the great work!
'make' year for Perl Posted Jan 8, 2009 6:39 UTC (Thu) by ChrisDolan (subscriber, #41017) [Link] It's definitely starting out to be a 'make' rather than 'break' year for Perl 6. As chromatic says, there have been 14 on-time, monthly releases of the Rakudo implementation of Perl 6. I've been writing a PDF parser in Perl 6 as a way to learn the language. Already, I find the code more concise AND more readable than my Perl 5 implementation.
'make' year for Perl Posted Jan 8, 2009 8:15 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Which Linux distribution has a working perl6 implementation?
'make' year for Perl Posted Jan 8, 2009 10:33 UTC (Thu) by rwmj (subscriber, #5474) [Link] Which Linux distribution has a working perl6 implementation? You might also ask which distributions are using Python 3. I guess Debian have packaged it. Fedora have passed on Python 3 (for now at least). Python 3 isn't backwards compatible, in a way which means you have to maintain two branches of your code. Whereas Perl 6 runs all existing Perl 5 code, no branching required. (Of course, I'm hoping that 2009 will be the year of the strongly-typed HM-based functional language, and we can finally give all dynamic languages the heave-ho in order to write better quality software). Rich.
'make' year for Perl Posted Jan 8, 2009 17:50 UTC (Thu) by lysse (guest, #3190) [Link]
"Better quality" surely remains an unproven assertion in this context - possibly even an unproveable one.
'make' year for Perl Posted Jan 8, 2009 17:59 UTC (Thu) by rwmj (subscriber, #5474) [Link] Well, I'd certainly like the compiler to identify some of the bugs for me earlier, instead of me having to try in vain to test every path through the code. My time is valuable, and wasting in tracking bugs and testing things that can be easily found by the compiler is just stupid. But hey, most people are still writing C that lets you stomp all over memory (when, that is, you're not sitting there worrying about who owns that bit of memory and who is responsible for freeing it). Rich.
'make' year for Perl Posted Jan 9, 2009 0:32 UTC (Fri) by lysse (guest, #3190) [Link]
As I understand it, one of the advantages of increased dynamism in one's language environment is that one can write code with a reduced number of paths through it. Ultimately - even truistically - the only way to write code with fewer bugs is to write less code.
The ideal for a compiler (or a language, maybe?) is that it is able to separate, as far as is possible, those bits of the program which can be precomputed (eg. type information) and precompute them, leaving only those bits which actually depend on real-time input for runtime. However, it's not readily apparent to me that languages such as Haskell - which impose a strict separation between compilation and execution, with the aim of doing as much reduction as possible in the former - are more capable of doing that than languages such as Lisp - which effectively abolish the distinction between the two, allowing the full power of the execution environment to be present at compilation; I suspect that the relative power of the two approaches comes down purely to personal preference, or "which confuses/annoys me less", and that there's no inherent superiority in either approach.
'make' year for Perl Posted Jan 9, 2009 1:42 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
while I agree that writing less code tends to generate fewer bugs, I adamantly disagree with the statement that the only way to write code with fewer bugs is to write less code.
even the statement that less code => fewer bugs is only true if all else remains equal. not all lines of code are the same. 100 lines of simple commands can be substantially less buggy than 5 lines of library calls with 50 options to each call.
using the language that best matches the abstraction of your code both decreases the lines of code needed, and decreases the errors. but the big win is in the fit, not in the lines of code.
'make' year for Perl Posted Jan 9, 2009 17:27 UTC (Fri) by lysse (guest, #3190) [Link]
> even the statement that less code => fewer bugs is only true if all else remains equal. not all lines of code are the same. 100 lines of simple commands can be substantially less buggy than 5 lines of library calls with 50 options to each call.
I realised after I'd posted that what I'd written was a bit ambiguous on precisely this point - so for the record, I am in complete agreement with you on this point. Indeed, in some ways libraries offer the worst of both worlds - they are neither designed to be specific to the task at hand, nor necessarily as well-debugged as their generality would necessitate - but that's a rant for another day. Please don't think I'm lending support to the "if there's a library for it, use the library" school of coding! Rather, I regard using a library as outsourcing; you're still responsible for every line of code in that library connected with the parts of it you're using, even though you delegated the authorship of the code you're using to the library's authors.
But I'm going to abandon this conversation at this point, anyway, because the one thing that's become more apparent to me than anything else over the 15 years I've been paying attention is that whatever anyone says about programming, and however anodynely they seek to express it, someone will come along and disagree with it in the violent and unshakeable conviction that they Know the Truth about it and have a Duty to Correct the Evil Lies - and if (but only if) you're really really lucky, they haven't misunderstood the first half of the second sentence to which they're replying and gone off half cocked. Worse, I've been that person way too often myself. So forgive me if I skip the whole damn sideshow this time; it's old and tedious and does absolutely nothing for anyone, and it disproportionately upsets me.
'make' year for Perl Posted Jan 9, 2009 19:10 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
no problem. I've just seen too many people who believe the letter of your initial statement that I didn't want to leave it sit.
I agree with the rest of your statements as well.
'make' year for Perl Posted Jan 10, 2009 6:30 UTC (Sat) by Ze (guest, #54182) [Link]
>>As I understand it, one of the advantages of increased dynamism in one's language environment is that one can write code with a reduced number of paths through it.
Whoever said that lied to you. A dynamic language has just as many paths through it. Just some of them are generated by the compiler/interpreter. The downside is since you give it less constraints it can do less optimisation and more importantly less error checking. >>Ultimately - even truistically - the only way to write code with fewer bugs is to write less code. Yes but that means less functionality.
>>The ideal for a compiler (or a language, maybe?) is that it is able to separate, as far as is possible, those bits of the program which can be precomputed (eg. type information) and precompute them, leaving only those bits which actually depend on real-time input for runtime. However, it's not readily apparent to me that languages such as Haskell - which impose a strict separation between compilation and execution, with the aim of doing as much reduction as possible in the former - are more capable of doing that than languages such as Lisp - which effectively abolish the distinction between the two, allowing the full power of the execution environment to be present at compilation;
The languages which separate compilation and execution (which btw isn't a restriction of the language but rather of the tools we choose to write , we could write an interpreter for c++ if we wanted).
The power that some languages have is they can create code on the fly. Ironically this was something that assembly had but when it came to write 'c' it was stripped out. It's a feature that's rarely needed or desirable. It's far more often misused than it used correctly.
If one wished , one could add an 'eval' to compiled languages by seperately compiling the extra code as needed and having a few constraints on optimisations for the original code. One particular optimisation that we would need to be very careful with is where instead of having two variables 'foo' and 'bar' we instead alias 'bar' to 'foo' since our analysis shows that 'foo' and 'bar' always have the same value.
>>I suspect that the relative power of the two approaches comes down purely to personal preference, or "which confuses/annoys me less", and that there's no inherent superiority in either approach.
Consider the wasted time spent reanalysing a program every time you run it? and consider that you need to run it anyway to test it. Why not trade some of that reanalysis time for better optimisation? or time you could spend doing other things?
IMHO that was one of the things that scripting has historically got wrong but that's due to the fact that historically they didn't create an intermediate format but rather put the code into an 'abstract syntax tree' and interpreted it from that. That has changed though since a lot of them convert the AST into an intermediate form that is more linear and then interpret that.
Unfortunately it's one of the things that history has landed in our laps and it's not something we'll rid ourselves of soon.
'make' year for Perl Posted Jan 11, 2009 2:49 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
compiled vs interpreted languages are a perfect example of what Linus has said about git, performance is a feature in and of itself, and at some point performance isn't just about doing things a in less time, but it fundamentally changes how you do things.
the speed of the edit-compile-test loop is the key difference between languages.
for traditional compiled languages the compile step takes a significant amount of time, so you do more work between compile steps.
for interpreted languages the 'compile' step is invisable to the user (it exists to some extent, but it's part of the run), so the tendancy becomes to tweak one thing, test it, then go to the next.
depending on what the testing steps require a project may fit better into one model than the other. small projects or projects that are generally stateless (many web projects for example) are much faster to develop with an interpreted language, projects that take a long time to test (it may be that they have a lot of state in them and so take many steps to test the change) don't benifit from the interitive approach of interpreted languages, and so the compile step doesn't hurt as much, and the other advantages in traditional compiled langages like strong typing and faster run-time performance are still there, so they tend to be better done using a 'compiled' language
now, in many cases the langugage is not selected based on what's best for the project, and many cases where the project has shifted over time (what started as a quick and simple program grew to be a monster), so you see a lot of projects written and maintained in inappropriate langugaes
it would be nice if there were interpreters and compilers for the same language so that development could take advantage of the strengths of the interpreted approach and production could take advantage of the compiled approach, but such situations are very rare.
'make' year for Perl Posted Jan 10, 2009 13:24 UTC (Sat) by epa (subscriber, #39769) [Link] Whereas Perl 6 runs all existing Perl 5 code, no branching required.Huh? You seem to be comparing an existing, working program (Python 3) with something that does not exist yet. Or have I missed something, and a Perl 6 implementation that 'runs all existing Perl 5 code' has been released without anyone noticing? I am aware that the Parrot and Rakudo developers have been making good progress. That is not the same as saying that Perl 6 has been released in anything like a usable state, or will be in the next 12 months. According to the current road map there are a couple of years to wait.
'make' year for Perl Posted Jan 8, 2009 14:52 UTC (Thu) by tetromino (subscriber, #33846) [Link]
None, for the obvious reason that perl6 is not yet finished.
Basically, during the second half of 2008, the Parrot virtual machine and the Rakudo Perl 6 compiler have made tremendous progress. You can now write useful programs in Perl 6, as long as you restrict yourself to the (large) subset of the language that Rakudo supports.
But the work is not yet finished; realistically, it will take a year to implement all the missing features. And even when 6.0 is released, it will take a while before distributions adopt it - just look at how many distros have made the switch to Python 3.
'make' year for Perl Posted Jan 8, 2009 20:49 UTC (Thu) by chromatic (guest, #26207) [Link]
We have Debian packages for Parrot and a spec file for RPM-based distributions. Our milestones for the next couple of Parrot releases include the ability to run Rakudo from an installed Parrot, so we should be able to provide Rakudo packages to free software operating systems within the next couple of months.
'make' year for Perl Posted Jan 8, 2009 9:34 UTC (Thu) by Ze (guest, #54182) [Link]
>Already, I find the code more concise AND more readable than my Perl 5 implementation.
That will slow the flow of developers moving to other languages like python and ruby , however it won't reverse the trend. To reverse the trend it needs to be compelling to the people who left and to new developers.
Personally I'm not a huge fan of any of them , but for some reason I've got an irrational hatred of python. I do like using tabs/leading line space as block delimiters rather than {} or begin/end though. I'd still keep () for function calls and control statements though.
3D Graphics Posted Jan 8, 2009 10:17 UTC (Thu) by pjm (subscriber, #2080) [Link] 3D graphics will be a solved problem on Linux systems. We will no longer be second to other systems with regard to functionality or performance Just a clarification of the prediction: does on Linux systems mean/imply with Free Software ? I'm not a 3D user, but was under the impression that performance was already roughly the same as on other systems so long as one was prepared to use proprietary drivers and suffer the associated version incompatibilities and other upgrade difficulties.
3D Graphics Posted Jan 8, 2009 16:26 UTC (Thu) by xav (subscriber, #18536) [Link]
Obviously he meant "with Free Software" as long as one buys ATi or Intel hardware.
That say I don't hold my breath (I've waited for so long). I think we'll probably have basic 3D this year (i.e. Compiz working on all current radeons by june), but having the drivers match the proprietary NVIDIA one in terms of features and performance is far away.
3D Graphics Posted Jan 8, 2009 20:20 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Via also made some progress.
nVidia's devices will be more expensive (= take more work to use properly) for OEMs.
A formerly friendly company may pull an SCO Posted Jan 8, 2009 10:26 UTC (Thu) by rwmj (subscriber, #5474) [Link]
Do we think Sun?
A formerly friendly company may pull an SCO Posted Jan 8, 2009 14:04 UTC (Thu) by corbet (editor, #1) [Link] I made a real point of not naming a company. Should this unfortunate prediction come to pass, it may well come from a direction which surprises almost everybody.
A formerly friendly company may pull an SCO Posted Jan 8, 2009 17:30 UTC (Thu) by felixfix (subscriber, #242) [Link]
Indeed. SCO used to be a linux friendly company, albeit not very successful, which may have been why they changed. Desperation and greed can be quite surprising when mixed together.
A formerly friendly company may pull an SCO Posted Jan 8, 2009 14:53 UTC (Thu) by pr1268 (subscriber, #24648) [Link] That's. Just. Scary. Especially given how hypocritical Jonathan Schwartz would look after his "Innovate, not Litigate" blog entry.
A formerly friendly company may pull an SCO Posted Jan 8, 2009 17:52 UTC (Thu) by lysse (guest, #3190) [Link]
Yes, but consider that Sun's shareholders might depose Schwartz and install a more bottom-line-friendly CEO.
A formerly friendly company may pull an SCO Posted Jan 8, 2009 18:36 UTC (Thu) by pr1268 (subscriber, #24648) [Link] Do you mean dispose Schwartz?
A formerly friendly company may pull an SCO Posted Jan 8, 2009 19:47 UTC (Thu) by knobunc (subscriber, #4678) [Link]
No. Depose is right.
"To remove (a monarch or political leader) from power, particularly without violence."
Depose is correct Posted Jan 8, 2009 20:13 UTC (Thu) by pr1268 (subscriber, #24648) [Link] I stand corrected. I was thinking of the 2nd definition of depose at Dictionary.com. Regardless, it'd be unfortunate if it happened (at Sun or any other company). Although, I'd like to think that Linux and Open Source would prevail yet again should this occur.
A formerly friendly company may pull an SCO Posted Jan 9, 2009 0:32 UTC (Fri) by lysse (guest, #3190) [Link]
Thanks. ;)
A formerly friendly company may pull an SCO Posted Jan 10, 2009 23:35 UTC (Sat) by jordanb (guest, #45668) [Link]
Sun has far too much legitimate business left to pull a SCO. Companies that still have substantial business in this industry don't become IP trolls because they're still exposed to counter-suits. IP trolling is what you do as a last ditch effort to pay off your creditors when you have nothing left. SCO was essentially an IP troll -- albeit backed by Microsoft and more directed at FUD than most of them, for political reasons.
While one could see Schwartz deposed and Sun redirected away from OSS, patent trolling isn't what they'd be directed towards in the near term.
To be honest if I had my guess it'd be one of the little bottom feeders like Xandros, either that or one of the un-dead fossils that are already mostly employ lawyers, like SGI.
Of the big guys the most likely suspect is Novell.
Perl Posted Jan 8, 2009 10:55 UTC (Thu) by job (guest, #670) [Link]
Labeling Perl a legacy language is a bit harsh. That the language hasn't been updated in the last decade is also a sign of maturity, much as the Bourne shell which could hardly be described as legacy.
It still handles day to day problems such as Unicode better than Python/Ruby, and last time I checked it was faster too. Last time I needed to talk SOAP with a Microsoft environment Perl did what Python couldn't. That said, it's far from perfect, and I also would like to see Perl 6 succeed. But from that it will probably take many years until everyone has migrated to it.
Perl Posted Jan 8, 2009 20:53 UTC (Thu) by chromatic (guest, #26207) [Link] That the language hasn't been updated in the last decade is also a sign of maturity.... That's not true in the case of Perl, though. Perl 5.10 has great improvements in the regex engine, some of which include user-visible improvements. In particular, I find named captures tremendously useful. given/when is also a powerful simplifying force. You also shouldn't discount language evolution in the form of CPAN distributions. I won't give up Mouse/Moose, and I want to see them as core language features. They didn't exist ten years ago.
Minor typo Posted Jan 8, 2009 12:42 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]
>make the dump to a DVCS
jump?
Minor typo Posted Jan 8, 2009 14:11 UTC (Thu) by vonbrand (subscriber, #4458) [Link] > > make the dump to a DVCS > jump? Nope, dump is right. Take the code out of the legacy system, dump it into the DVCS of your choice ;-)
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 12:55 UTC (Thu) by cde (guest, #46554) [Link]
I have to say, it's high time to release Lenny. I've been using the di-beta2 for more than 6 months and it's rock stable. Of all the Debian version I've used since potato, it's by far the best.
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 14:33 UTC (Thu) by hmh (subscriber, #3838) [Link]
But we didn't have the obServerCrash yet. There is one within one month of a new stable release, aways...
Well, maybe the mess with the firmware GR might have satisfied Eris enough, for once. Who knows...
The Grumpy Editor's guide to 2009 Posted Jan 8, 2009 17:06 UTC (Thu) by cine (guest, #5597) [Link]
Renewed my subscription a few months ago for another 2 years, extending the already 6 years of continuous reading. Very much enjoy your work :)
make-or-break year for Perl Posted Jan 12, 2009 2:12 UTC (Mon) by nicku (subscriber, #777) [Link] It will be a make-or-break year for Perl. If the Perl developers cannot either bring new life to Perl 5 or turn Perl 6 into something real, this language will, by the end of the year, have moved well down the road to "legacy" status. It's mainly a problem of perception. If Sun owned Perl, then 5.10 would have been released as version 10 and the waffle in Slashdot about Perl 6 would be irrelevant. At Optus Internet Services Engineering, we write our code productively in Perl and occasionally in C. New projects are written in Perl. My team enjoys writing Perl. Perl simply need some better marketing.
The Grumpy Editor's guide to 2009 Posted Jan 13, 2009 3:14 UTC (Tue) by paulmfoster (subscriber, #17313) [Link]
Unless you know something we don't, linux.com is not "demised". According to their announcement on 1 Jan, it appears they are merging with or being bought out by someone. (For "legal reasons" they can't detail things right now.) I imagine they will emerge with a different paradigm. As I recall sometime in 2008, the parent company changed its name to SoureForge and asserted its ownership over linux.com and other assets.
If you hear something before we do, please let us know.
|
|||||||||||||