They are screwed either way. If they give it away for free, people will complain that microsoft is product dumping. If they charge, people will complain that they are making money on their software bugs.
In other words, given their current position as a convicted monopoly, the suitable option is not to get into the anti-virus business at all. Apparently they haven't decided to take that option. Is it any surprise they get blamed no matter which subtle variant of a fundamentally foolish decision they make?
It will be interesting to see which OS gets MACL out of the box first a Linux system, or Windows. Microsoft has had a 15 year head start, but RedHat has been trying to get SeLinux into Fedora for over a year now. If I had to bet, I know where my money would go.
SELinux is in Fedora Core 3 now, so Fedora is already there. To be fair, it defaults to a fairly permissive policy, only locking down various services (BIND, Apache, etc.) in any serious way. Doing more than that gets tricky because there are enough applications out there that don't properly respect the sort of boundaries SELinux would like to apply... and having a policy where a number of applications just break is not currently tenable.
Think of it as akin to the Windows "have to be Administrator" problem: because it wasn't an issue for a long time, a lot of software doesn't behave properly with regard to security, so properly imposing restrictions isn't viable. Of course Redhat is working hard to get stuff fixed, and the more often SELinux is in there by default the more developers will try and respect the constraints that ought to be applied.
I'm sooo sick of people looking in Task Manager then saying how much an application sucks because of how much "memory" it uses. For the most part, memory is not a factor.
You think that's annoying? You should try having to put up with all people who complain "X is sooooo bloated" because they looked at memory usage on top but have no idea how it is calculated for X, nor what the figure really means. Every single article that has any mention of X11 gets at least 15 posts all saying X is bloated based on top, and every time there are a bunch of people who give long and careful explanations as to why the figures in top are the way they are. And then the next article comes along and a whole bunch of people decide to demonstrate exactly how little they've learned...
Is it me, or does this look worse than the stock ubuntu install Gnome?
If you look through the screenshots, it is an Ubuntu install, and has a number of the Ubuntu customisations already, so it's not even very representative of what the general GNOME 2.10 user is going to get. All up, the screenshots aren't worth your time, head here to see what changes GNOME 2.10 has.
A changelog be more useful than crappy screenshots...
Indeed, this story seems to be a waste of time. If you want screenshots that actually show you what you're getting that's different, look here. It's old news (it's been up for some time), but it gives you a far better idea of what you're getting.
Would be nice with some comments and screenshots showing whats new. I really couldnt tell any difference from the previous releases (could have tried hrder but I m lazy:) Also that theme muust be the most ugly one they could have choosen...
I think this is what you're looking for - of course this one is "old news" having been posted on Slashdot previously. It does a lot better of job of actually showing you what to expect in GNOME 2.10 than the selection of Ubuntu screenshots from OSDir though.
If you wish to say (for example) "I propose that we normalize on milliseconds-since-epoch, and represent that as a base N number, which would be useful for compressing times in URLs", yeah, that's probably patentable. Base 10 is probably excluded due to prior art.
My point is not whether that is patentable, but that it shouldn't be. It's silly. A method and system for encoding a general numeric value in a printable form has been well known for a long time (Base64 or MIME encoding), and the variants and ideas involved are obvious to anyone who has ever done any work whatsoever in those fields. If general numbers are well covered by prior art, why should specific kinds of numbers now be patentable?
Perhaps you haen't done much math in various bases, or perhaps you haven't played with any compression schemes. In that case this particular system may not be obvious to you. It is quite obvious to "anyone skilled in the art". This is akin to someone patenting a "special new engine" that is vastly different from every other engine ever constructed by dint of the fact that it has been "specially constructed for North American roads" by adjusting the timing slightly.
The thing is, lots of gnustep dev like 1) the floating menus 2) the list selector widgets (personally that's one of my favorite widgets -- and by the way they still exist on Cocoa, and are used..) 3) the "empty" scrollbars is NOT a bad idea.
And more power to them, because if they like it, that's great. Just do't expect me to think its wonderful and be scrambling to move to their desktop system. I'm sure all the GNUstep devs like the GUI the way it is - if they disliked it that much, they'd be programming something else. But that is exactly the reason the GUI looks and acts as it does: most of the coders are, I suspect, people who love and are nostalgic for the NeXT system. In the meantime the rest of the world has moved on. I think it's fantastic that they've managed to create the system they have. They just shouldn't be too surprised if there aren't a lot of people who share their passion for 90s NeXT GUI technology.
I've seen that page. There is one skin that doesn't address some of the fundamental issues that make GNUstep applications to ugly and clunky looking. Adding gradients does not a good GUI make. Consider the Industrial theme for GTK - very popular, and a very nice theme, but it is also fairly flat and simple.
The big issues I tend to have with GNUstep GUIs are
(1) The big chunky controls. In comparison to the font size all the GNUstep controls are huge boxy things adding to the cluttered look.
(2) List selector widgets: You know the ones, the NeXT file manager used them. They need horizontal scrollbars usually. As far as GUIs go that's not a very efficient or pretty way to manage things. NeXT had some very good ideas. That wasn't one of them. The world has moved on.
(3) Floating menus: MacOS puts the app menus across the top of the screen to "obey Fitt's law", most everyone else has them at the top of the application. GNUstep kindly has them as bizarre free floating objects. Once again, not one of NeXT's better ideas. Can't we move on from slavishly copying NeXT?
(4) Empty scroll troughs: Nice big (due to those huge widget controls) areas of the screen that have no obvious function until you get enough items for the scrollbar to appear. Either put a full size scrollbar in there, or have the scroll widgets appear when required. Again, slavishly copying NeXT even on their "not so good" ideas.
There's a reason no one else took up these particular ideas from NeXT, not even MacOS X which is essentially the next generation NeXT. The reason is that they aren't very good - at the time (early 90s) they looked promising, but we've had GUIs for a long time now, and ideas of what works and what doesn't have come a long way. For some reason GNUstep slavishly follows NeXT even in their foolish early 90s mistakes.
The color scheme is a large part of it. It's also the fonts, the the size of the widgets - all the buttons and list dividers etc. all look kind of chunky and stand out, adding to the "clutter" look. By contrast in the MacOS X screenshot the obvious UI elements are the messages themselves. It doesn't need to be all gel looking like MacOS X, but even a theme more akin to GTK Industrial or KDE Plastik along with better fonts would go a long way to making the application look much nicer and more inviting.
To be honest, yes. You can see the issue most clearly by comparing this and this. One is GNUMail compiled under GNUstep, the other is the very same GNUMail compiled under MacOS X.
To my eye, for reasons I can't fully explain, at first glance the GNUstep version looks more cluttered and complicated even though some inspection will show all the same UI elements in the same places with the same icons. It's the colors, and the sizing and style of the widgets, and just the general feel given off by the look as a whole.
It should be noted that most US politicians perform in almost exactly the same way. They have a list of significant talking points/pre-prepared answers and no matter what the question they simply answer with the a talking point, which they can then give a short speech about (ideally it even includes a nice anecdote). The problem is not so much that marketers and politicians do this (is it any surprise? they get to give long speeches about whatever they want to talk about), the problem is that the interviewers never call them on this.
Polticians in Europe often do get dragged over the coals for faling to answer a question. It appears, however, that when interviewing CEOs and marketers European interviewers still don't feel inclined to go for the throat with non-answers. A shame.
As far as I can tell, none of the mapping sites encode information this way, even though it might be advantageous for them to do so. If somebody can show me a case where they do so of course I'd retract. But I'd argue that since people can and should have done this before, but haven't that makes it non-obvious.
The design is defined by the constraints. The constraints are: A compact encoding of numeric value, such that the encoded form can be in a URL.
The obvious manner for a printable compact encoding of a numeric value is Base64. Base64 isn't URL safe though - URLs don't distinguish case, and some of the extended characters won't be valid in URLs. So let's use the Base64 set, less the non-alphanumerics, and uppercase letters. That leaves you with 26 chars from a-z and 10 from 0-9 for 36 in total. All of these steps so far are very obvious for the given problem constraints. The step of choosing to drop vowels to bring the total number of chars to 30 for base30 encoding is somewhat arbitrary (I probably would have decided to just use 0-5 and base32 instead) but hardly represents a stunning insight, as certainly base30 or base32 are the obvious nearest "round number" choices.
Why has no one does this before? Mostly because the problem (encoding lat long for inclusion in a URL) is relatively new. Has anyone done anything similar beore? tinyURL certainly have the issue of compactly encoding a number (an index into a databse of long URLs rather than a lat/long) for inclusion in a URL, and their solution looks suspiciously similar to what I outlined above.
Essentially you are saying that the "novel" part is
(1) Dropping vowels instead of other characters (2) using base30 instead of base32 (3) using it for lat/long encoding
Now (1) and (2) are arbitrary choices, not inventions. If you're going to allow that, then I can patent base64 encoding where I use @ instead of +. As for (3) - you're saying it is novel to use such an encoding specifically for lat/long numbers, as opposed to any general numeric argument? That's the same as the "add 'on the internet'" to anything to make it patentable concepts. I may as well use such an encoding to compactly represent dates and times in URLs (for online calendaring software maybe). I mean, the exact same encoding scheme, but for dates and times. No one has ever done that before, so it must be truly novel and creative (as opposed to obvious once the problem is stated) right?
What are you planning on exchanging it with? If it's Photoshop then use PSD - GIMP can save to PSD quite happily. What else are you planning on using that requires you to save layer info?
As some have pointed out, some of these are valid complaints, but some are just silly.
open a OpenOffice document in AbiWord
Yes, its unfortunate that doesn't work. It isn't for lack of potential interoperability though - both formats are open and documented. The fact that the Abiword team hasn't gotten around to writing an import filter is a little disappointing, but if you're going to damn them for that:
Try opening an OpenOffice document in Microsoft Word.
Not much interoperability from Microsoft either. OpenOffice is fairly widely used and popular, and the file format readily documented. It wouldn't be hard at all for Microsoft ot be interoperable if they wanted to be.
- try to edit a LaTeX document with Abiword or OpenOffice
Try to open a QuarkXPress document in Microsoft Word. How about an Adobe InDesign document in Microsoft Word? What's that? A different application domain? Then please think again about your example. TeX is not a word processor, even if there are programs like LyX that do a good job of providing a word processor like interface for it.
- try to open a Gimp xcf in anything beside Gimp
Try opening a PSD document in anything besides Photoshop. There are actually some programs that read it (like GIMP, heh), but your remarkably interoperable Microsoft Office suite will choke on it. Likewise there are programs that will read xcf (its an open documented format after all), but most don't expect to need to, so don't bother. As to GIMP - I hear they're working on an even more open and easy to access format.
That's a point for debate. Microsoft has already implied they might integrate MSN search into all searching on your PC. That is the "find files" and "search email" is also linked in with MSN search. You don't fire up a web browser, go to a page, and hit search anymore, you just hit the search button on your desktop/Start Menu to get a search dialog and allow "internet search" as well as desktop search...
That will be what Microsoft will be looking to do if they go the "integration" route.
Fellow NZer, Enterprise so thoroughly blew goats (I have proof) that it was more than capable of downing itself.
I'll take your word for it. I've seen a grand total of 2 episodes which were both rather poor, but people kept saying it "got better" so having not really seen it, I decided to give it the benefit of the doubt and assumed it attained mediocrity.
Programming open source, releasing your code, is something you should do for your own enjoyment. There have been a number of cases of developers becoming disillusioned because their open source project failed to generate them any money, or got forked off into something else that became more popular. As disconcerting as that can be, it is a natural result of releasing your code under a license that allows such things. If you want control, if you want to be guaranteed money, then you should license your code accordingly.
Open source code is about scratching your own itch, doing what interests you (and potentially no one else), and the pleasures of problem solving associated with writing software. Yes, some open source projects have resulted in success for their developers because it turned out that what that person was interested in writing was somethign that a lot of people were interested in using. In the end though, almost all the really successful open source coders are people who did what they wanted to do for their own reasons. People who are passionate and interested in what they're coding (an advantage an open source coder has, being able to code whatever interests them) are far more likely to write good code than those disinterested in their projects, which has helped make some open source projects highly successful, but it is no guarantee of success or popularity.
The advantage of open source from the developers perspective is that they have the opportunity to do exactly what they want to do, exactly what interests them. The disadvantage is that what interests you may very well be of interest to very few others.
They aired the crappy Voyager series for 7 (too) long seasons without killing it and now they kill not-so-bad Enterprise?!?
Well, yeah. They already spent 7 seasons shedding viewers left and right, so there was hardly any viewership left for Enterprise. It needed to be so good it attracted viewers back. It wasn't close to doing that - it was just not as bad as Voyager... and any fan who stayed with the franchise through Voyager would have watched anything, so it didn't matter whether Enterprise was a bit better (it could hardly have been worse).
Think of it this way: Voyager killed Enterprise, it just took a while for the blood to drain and the franchise to finally die.
Good for movies too. Building a rendering cluster each time you make a movie is expensive.
Depends on how you look at it. Weta Digital spent a fortune on a render farm for LOTR, but that money got recouped on the film, and they now rent on time on the render farm to universities, research groups, and businesses. If you really need that powerful cluster now you may as well build your own and then sell off time on it at 90c per CPU hour when you're done and it's not under heavy load anymore.
That is not where the problem lies. The additional problems in ascending order of size are --
1 -- (for the non-geek mum/dad user) getting used to the CLI
2 -- (for quite a lot of others too) figuring out what to do if
apt-get install programx coughs over a dependency issue and shows up with screeds of error messages.
This is nowhere near as hard as you seem to think.
(1) Install Synaptic to do the package management (you know, like Ubuntu and Connectiva do by default), and they'll never have to look at a command line.
(2) They'll do the same thing they do when a Windows Setup.exe barfs with an error message. What's the problem? Neither happens very often at all (unless you go mixing your repositories... which will only happen if you know what you're doing... which will mean you can resolve the dependencies yourself).
For third party (non-distro provided) packages there's things like Autopackage, which while still in development will hopefully become the standard way for any non-distro packagers to package things up.
So far the consensus here was that it is Microsoft behind the whole SCO debacle -- but what if IBM knows better (and I guess I'd bet my $10 on THEM knowing better;-) ).... What do they know that I do not?
IBM knows that Intel knows all about Itanium, its roadmaps, schedules, and delays. IBM knows that Intel has a good idea of what they told SCO about Itanium schedules and delays. Given that SCO is now down to claiming that any funny business about purloining code went on during Project Monteray, on which IBM and SCO cooperated, and that that was largely about AIX on Itanium, details about Itanium and what SCO knew about it are important.
There are perfectly straightforward, perfectly innocent explanations for why IBM would want information from Intel, and oddly enough they fit the current major issues of the case far better than any wild and extravagant theories about Intel conspiring to bring IBM down.
So what does IBM know that you don't? IBM know what they're talking about.
For all the speculation about IBM vs. Intel, it seems to me that this post had the most sensible explanation of what's going on here. The SCO case is about Project Monteray now, which was an AIX on Itanium endeavour. It makes perfect sense to drag Intel in to discuss what SCO was told by Intel about Itanium, and its various delays.
All this jumping to conclusions about IBM and PPC slugging it out with Intel is unbelievably silly given this other explanation that fits the facts (and the case) far better. Can we cut the stupid conspiracy theories?
But hey, I'll take a BSD-licensed office suite that can perfectly read MS formats anyday. For that matter, this may not even conflict with the OO.org licensing.
You don't need to BSD license the whole suite, you just need to have an MS Office document reader library that is BSD licensed.
Slashdot Mirror
They are screwed either way. If they give it away for free, people will complain that microsoft is product dumping. If they charge, people will complain that they are making money on their software bugs.
In other words, given their current position as a convicted monopoly, the suitable option is not to get into the anti-virus business at all. Apparently they haven't decided to take that option. Is it any surprise they get blamed no matter which subtle variant of a fundamentally foolish decision they make?
Jedidiah.
It will be interesting to see which OS gets MACL out of the box first a Linux system, or Windows. Microsoft has had a 15 year head start, but RedHat has been trying to get SeLinux into Fedora for over a year now. If I had to bet, I know where my money would go.
SELinux is in Fedora Core 3 now, so Fedora is already there. To be fair, it defaults to a fairly permissive policy, only locking down various services (BIND, Apache, etc.) in any serious way. Doing more than that gets tricky because there are enough applications out there that don't properly respect the sort of boundaries SELinux would like to apply... and having a policy where a number of applications just break is not currently tenable.
Think of it as akin to the Windows "have to be Administrator" problem: because it wasn't an issue for a long time, a lot of software doesn't behave properly with regard to security, so properly imposing restrictions isn't viable. Of course Redhat is working hard to get stuff fixed, and the more often SELinux is in there by default the more developers will try and respect the constraints that ought to be applied.
Jedidiah.
I'm sooo sick of people looking in Task Manager then saying how much an application sucks because of how much "memory" it uses. For the most part, memory is not a factor.
You think that's annoying? You should try having to put up with all people who complain "X is sooooo bloated" because they looked at memory usage on top but have no idea how it is calculated for X, nor what the figure really means. Every single article that has any mention of X11 gets at least 15 posts all saying X is bloated based on top, and every time there are a bunch of people who give long and careful explanations as to why the figures in top are the way they are. And then the next article comes along and a whole bunch of people decide to demonstrate exactly how little they've learned...
Jedidiah.
Is it me, or does this look worse than the stock ubuntu install Gnome?
If you look through the screenshots, it is an Ubuntu install, and has a number of the Ubuntu customisations already, so it's not even very representative of what the general GNOME 2.10 user is going to get. All up, the screenshots aren't worth your time, head here to see what changes GNOME 2.10 has.
Jedidiah.
A changelog be more useful than crappy screenshots...
Indeed, this story seems to be a waste of time. If you want screenshots that actually show you what you're getting that's different, look here. It's old news (it's been up for some time), but it gives you a far better idea of what you're getting.
Jedidiah.
Would be nice with some comments and screenshots showing whats new. I really couldnt tell any difference from the previous releases (could have tried hrder but I m lazy:) Also that theme muust be the most ugly one they could have choosen...
I think this is what you're looking for - of course this one is "old news" having been posted on Slashdot previously. It does a lot better of job of actually showing you what to expect in GNOME 2.10 than the selection of Ubuntu screenshots from OSDir though.
Jedidiah.
If you wish to say (for example) "I propose that we normalize on milliseconds-since-epoch, and represent that as a base N number, which would be useful for compressing times in URLs", yeah, that's probably patentable. Base 10 is probably excluded due to prior art.
My point is not whether that is patentable, but that it shouldn't be. It's silly. A method and system for encoding a general numeric value in a printable form has been well known for a long time (Base64 or MIME encoding), and the variants and ideas involved are obvious to anyone who has ever done any work whatsoever in those fields. If general numbers are well covered by prior art, why should specific kinds of numbers now be patentable?
Perhaps you haen't done much math in various bases, or perhaps you haven't played with any compression schemes. In that case this particular system may not be obvious to you. It is quite obvious to "anyone skilled in the art". This is akin to someone patenting a "special new engine" that is vastly different from every other engine ever constructed by dint of the fact that it has been "specially constructed for North American roads" by adjusting the timing slightly.
Jedidiah.
The thing is, lots of gnustep dev like 1) the floating menus 2) the list selector widgets (personally that's one of my favorite widgets -- and by the way they still exist on Cocoa, and are used..) 3) the "empty" scrollbars is NOT a bad idea.
And more power to them, because if they like it, that's great. Just do't expect me to think its wonderful and be scrambling to move to their desktop system. I'm sure all the GNUstep devs like the GUI the way it is - if they disliked it that much, they'd be programming something else. But that is exactly the reason the GUI looks and acts as it does: most of the coders are, I suspect, people who love and are nostalgic for the NeXT system. In the meantime the rest of the world has moved on. I think it's fantastic that they've managed to create the system they have. They just shouldn't be too surprised if there aren't a lot of people who share their passion for 90s NeXT GUI technology.
Jedidiah.
I've seen that page. There is one skin that doesn't address some of the fundamental issues that make GNUstep applications to ugly and clunky looking. Adding gradients does not a good GUI make. Consider the Industrial theme for GTK - very popular, and a very nice theme, but it is also fairly flat and simple.
The big issues I tend to have with GNUstep GUIs are
(1) The big chunky controls. In comparison to the font size all the GNUstep controls are huge boxy things adding to the cluttered look.
(2) List selector widgets: You know the ones, the NeXT file manager used them. They need horizontal scrollbars usually. As far as GUIs go that's not a very efficient or pretty way to manage things. NeXT had some very good ideas. That wasn't one of them. The world has moved on.
(3) Floating menus: MacOS puts the app menus across the top of the screen to "obey Fitt's law", most everyone else has them at the top of the application. GNUstep kindly has them as bizarre free floating objects. Once again, not one of NeXT's better ideas. Can't we move on from slavishly copying NeXT?
(4) Empty scroll troughs: Nice big (due to those huge widget controls) areas of the screen that have no obvious function until you get enough items for the scrollbar to appear. Either put a full size scrollbar in there, or have the scroll widgets appear when required. Again, slavishly copying NeXT even on their "not so good" ideas.
There's a reason no one else took up these particular ideas from NeXT, not even MacOS X which is essentially the next generation NeXT. The reason is that they aren't very good - at the time (early 90s) they looked promising, but we've had GUIs for a long time now, and ideas of what works and what doesn't have come a long way. For some reason GNUstep slavishly follows NeXT even in their foolish early 90s mistakes.
Jedidiah.
The color scheme is a large part of it. It's also the fonts, the the size of the widgets - all the buttons and list dividers etc. all look kind of chunky and stand out, adding to the "clutter" look. By contrast in the MacOS X screenshot the obvious UI elements are the messages themselves. It doesn't need to be all gel looking like MacOS X, but even a theme more akin to GTK Industrial or KDE Plastik along with better fonts would go a long way to making the application look much nicer and more inviting.
Jedidiah.
To be honest, yes. You can see the issue most clearly by comparing this and this. One is GNUMail compiled under GNUstep, the other is the very same GNUMail compiled under MacOS X.
To my eye, for reasons I can't fully explain, at first glance the GNUstep version looks more cluttered and complicated even though some inspection will show all the same UI elements in the same places with the same icons. It's the colors, and the sizing and style of the widgets, and just the general feel given off by the look as a whole.
Jedidiah.
It should be noted that most US politicians perform in almost exactly the same way. They have a list of significant talking points/pre-prepared answers and no matter what the question they simply answer with the a talking point, which they can then give a short speech about (ideally it even includes a nice anecdote). The problem is not so much that marketers and politicians do this (is it any surprise? they get to give long speeches about whatever they want to talk about), the problem is that the interviewers never call them on this.
Polticians in Europe often do get dragged over the coals for faling to answer a question. It appears, however, that when interviewing CEOs and marketers European interviewers still don't feel inclined to go for the throat with non-answers. A shame.
Jedidiah.
As far as I can tell, none of the mapping sites encode information this way, even though it might be advantageous for them to do so. If somebody can show me a case where they do so of course I'd retract. But I'd argue that since people can and should have done this before, but haven't that makes it non-obvious.
The design is defined by the constraints. The constraints are: A compact encoding of numeric value, such that the encoded form can be in a URL.
The obvious manner for a printable compact encoding of a numeric value is Base64. Base64 isn't URL safe though - URLs don't distinguish case, and some of the extended characters won't be valid in URLs. So let's use the Base64 set, less the non-alphanumerics, and uppercase letters. That leaves you with 26 chars from a-z and 10 from 0-9 for 36 in total. All of these steps so far are very obvious for the given problem constraints. The step of choosing to drop vowels to bring the total number of chars to 30 for base30 encoding is somewhat arbitrary (I probably would have decided to just use 0-5 and base32 instead) but hardly represents a stunning insight, as certainly base30 or base32 are the obvious nearest "round number" choices.
Why has no one does this before? Mostly because the problem (encoding lat long for inclusion in a URL) is relatively new. Has anyone done anything similar beore? tinyURL certainly have the issue of compactly encoding a number (an index into a databse of long URLs rather than a lat/long) for inclusion in a URL, and their solution looks suspiciously similar to what I outlined above.
Essentially you are saying that the "novel" part is
(1) Dropping vowels instead of other characters
(2) using base30 instead of base32
(3) using it for lat/long encoding
Now (1) and (2) are arbitrary choices, not inventions. If you're going to allow that, then I can patent base64 encoding where I use @ instead of +. As for (3) - you're saying it is novel to use such an encoding specifically for lat/long numbers, as opposed to any general numeric argument? That's the same as the "add 'on the internet'" to anything to make it patentable concepts. I may as well use such an encoding to compactly represent dates and times in URLs (for online calendaring software maybe). I mean, the exact same encoding scheme, but for dates and times. No one has ever done that before, so it must be truly novel and creative (as opposed to obvious once the problem is stated) right?
Jedidiah.
What are you planning on exchanging it with? If it's Photoshop then use PSD - GIMP can save to PSD quite happily. What else are you planning on using that requires you to save layer info?
Jedidiah.
For the rest of us, 1TB is a lot of pr0n, or hundreds of Linux distributions.
I can see it now: the new HVD Knoppix, now with the entire contents of sourceforge!
Jedidiah.
As some have pointed out, some of these are valid complaints, but some are just silly.
open a OpenOffice document in AbiWord
Yes, its unfortunate that doesn't work. It isn't for lack of potential interoperability though - both formats are open and documented. The fact that the Abiword team hasn't gotten around to writing an import filter is a little disappointing, but if you're going to damn them for that:
Try opening an OpenOffice document in Microsoft Word.
Not much interoperability from Microsoft either. OpenOffice is fairly widely used and popular, and the file format readily documented. It wouldn't be hard at all for Microsoft ot be interoperable if they wanted to be.
- try to edit a LaTeX document with Abiword or OpenOffice
Try to open a QuarkXPress document in Microsoft Word. How about an Adobe InDesign document in Microsoft Word? What's that? A different application domain? Then please think again about your example. TeX is not a word processor, even if there are programs like LyX that do a good job of providing a word processor like interface for it.
- try to open a Gimp xcf in anything beside Gimp
Try opening a PSD document in anything besides Photoshop. There are actually some programs that read it (like GIMP, heh), but your remarkably interoperable Microsoft Office suite will choke on it. Likewise there are programs that will read xcf (its an open documented format after all), but most don't expect to need to, so don't bother. As to GIMP - I hear they're working on an even more open and easy to access format.
Jedidiah.
They can't bundle it with their OS
That's a point for debate. Microsoft has already implied they might integrate MSN search into all searching on your PC. That is the "find files" and "search email" is also linked in with MSN search. You don't fire up a web browser, go to a page, and hit search anymore, you just hit the search button on your desktop/Start Menu to get a search dialog and allow "internet search" as well as desktop search...
That will be what Microsoft will be looking to do if they go the "integration" route.
Jedidiah.
Fellow NZer, Enterprise so thoroughly blew goats (I have proof) that it was more than capable of downing itself.
I'll take your word for it. I've seen a grand total of 2 episodes which were both rather poor, but people kept saying it "got better" so having not really seen it, I decided to give it the benefit of the doubt and assumed it attained mediocrity.
Jedidiah.
Programming open source, releasing your code, is something you should do for your own enjoyment. There have been a number of cases of developers becoming disillusioned because their open source project failed to generate them any money, or got forked off into something else that became more popular. As disconcerting as that can be, it is a natural result of releasing your code under a license that allows such things. If you want control, if you want to be guaranteed money, then you should license your code accordingly.
Open source code is about scratching your own itch, doing what interests you (and potentially no one else), and the pleasures of problem solving associated with writing software. Yes, some open source projects have resulted in success for their developers because it turned out that what that person was interested in writing was somethign that a lot of people were interested in using. In the end though, almost all the really successful open source coders are people who did what they wanted to do for their own reasons. People who are passionate and interested in what they're coding (an advantage an open source coder has, being able to code whatever interests them) are far more likely to write good code than those disinterested in their projects, which has helped make some open source projects highly successful, but it is no guarantee of success or popularity.
The advantage of open source from the developers perspective is that they have the opportunity to do exactly what they want to do, exactly what interests them. The disadvantage is that what interests you may very well be of interest to very few others.
Jedidiah
They aired the crappy Voyager series for 7 (too) long seasons without killing it and now they kill not-so-bad Enterprise?!?
Well, yeah. They already spent 7 seasons shedding viewers left and right, so there was hardly any viewership left for Enterprise. It needed to be so good it attracted viewers back. It wasn't close to doing that - it was just not as bad as Voyager... and any fan who stayed with the franchise through Voyager would have watched anything, so it didn't matter whether Enterprise was a bit better (it could hardly have been worse).
Think of it this way: Voyager killed Enterprise, it just took a while for the blood to drain and the franchise to finally die.
Jedidiah.
Good for movies too. Building a rendering cluster each time you make a movie is expensive.
Depends on how you look at it. Weta Digital spent a fortune on a render farm for LOTR, but that money got recouped on the film, and they now rent on time on the render farm to universities, research groups, and businesses. If you really need that powerful cluster now you may as well build your own and then sell off time on it at 90c per CPU hour when you're done and it's not under heavy load anymore.
Jedidiah.
That is not where the problem lies. The additional problems in ascending order of size are --
1 -- (for the non-geek mum/dad user) getting used to the CLI
2 -- (for quite a lot of others too) figuring out what to do if
apt-get install programx
coughs over a dependency issue and shows up with screeds of error messages.
This is nowhere near as hard as you seem to think.
(1) Install Synaptic to do the package management (you know, like Ubuntu and Connectiva do by default), and they'll never have to look at a command line.
(2) They'll do the same thing they do when a Windows Setup.exe barfs with an error message. What's the problem? Neither happens very often at all (unless you go mixing your repositories... which will only happen if you know what you're doing... which will mean you can resolve the dependencies yourself).
For third party (non-distro provided) packages there's things like Autopackage, which while still in development will hopefully become the standard way for any non-distro packagers to package things up.
Jedidiah.
So far the consensus here was that it is Microsoft behind the whole SCO debacle -- but what if IBM knows better (and I guess I'd bet my $10 on THEM knowing better ;-) ). ... What do they know that I do not?
IBM knows that Intel knows all about Itanium, its roadmaps, schedules, and delays. IBM knows that Intel has a good idea of what they told SCO about Itanium schedules and delays. Given that SCO is now down to claiming that any funny business about purloining code went on during Project Monteray, on which IBM and SCO cooperated, and that that was largely about AIX on Itanium, details about Itanium and what SCO knew about it are important.
There are perfectly straightforward, perfectly innocent explanations for why IBM would want information from Intel, and oddly enough they fit the current major issues of the case far better than any wild and extravagant theories about Intel conspiring to bring IBM down.
So what does IBM know that you don't? IBM know what they're talking about.
Jedidiah.
For all the speculation about IBM vs. Intel, it seems to me that this post had the most sensible explanation of what's going on here. The SCO case is about Project Monteray now, which was an AIX on Itanium endeavour. It makes perfect sense to drag Intel in to discuss what SCO was told by Intel about Itanium, and its various delays.
All this jumping to conclusions about IBM and PPC slugging it out with Intel is unbelievably silly given this other explanation that fits the facts (and the case) far better. Can we cut the stupid conspiracy theories?
Jedidiah.
But hey, I'll take a BSD-licensed office suite that can perfectly read MS formats anyday. For that matter, this may not even conflict with the OO.org licensing.
You don't need to BSD license the whole suite, you just need to have an MS Office document reader library that is BSD licensed.
Jedidiah.