> hell, Outlook has code to automatically execute attachments at the time they're received
Does it still? I thought they'd finally taken that out. (I think it does still make it entirely too easy for the user to launch executable attachments though.)
> *all* users, even sensible and cautious ones, can be easily tricked into running > an executable because the user interface makes it look exactly like an ordinary file.
No, not all users. Only users who deliberately save random unidentified garbage, and not only that but save it to their desktop, of all places, and then go along happily click-click-clicking all over it. In other words, people who are just plain not bright enough to be trusted with a complex task such as operating a computer.
I will grant you that.desktop files are an inherently bad idea, because there *ARE* a lot of users out there who fit the above description. But saying that all users would be infected, including sensible and cautious ones, is just plain idiotic. Users who practice safe and sane computing have absolutely nothing to fear from this, unless there's some kind of attack vector whereby an attacker can cause a malicious.desktop file to be saved to the user's desktop (or menus, or wherever), and frankly, if an attacker can cause arbitrary content to be written to your drive, then you've got much bigger problems than the.desktop files.
> If you expect people to figure out whether a file is safe before "launching/opening" it, > then you are expecting people to solve something arguably harder than the "halting problem"
I think you've overstated that somewhat. If it came as an attachment to an email message, and you were not expecting to receive it, and you don't know what it is, and it's an _executable_ filetype, you generally don't need to know any more about it than that. Send it to/dev/null and have done.
Well, the OS is certainly not the only or even the primary factor in security. I don't know that I'd go so far as to say it doesn't matter at all.
> Viruses and Trojans require the user to not think and execute things willy-nilly.
Agreed, although in the case of an email attachment, a naively-designed mailreader greatly increases the likelihood that the user will do so. When a sane mailreader (e.g., Pegasus Mail) sees an attachment with a filetype or extension that suggests executable content, and the user tries to save the thing to the filesystem, the MUA presents a big fat scary dialog box with the phrase "VIRUS Warning" in the titlebar, the phrase "Possible VIRUS" in a bold header over the text that explains that the content is executable and potentially dangerous, and with the safe "No" option selected by default.
> Every regular use I have met that was infected simply clicked yes to every > dialog box they did not want to bother reading and understanding.
It used to be possible to get infected without taking any special action, if you used a certain extremely insecure mailreader whose initials are MSOE and received a dangerous attachment. I *think* this has been cleaned up somewhat now, although of course the users can still launch dangerous attachments if they choose to do so (and I believe it actually lets the user directly *launch* the thing, not just save it).
> You get an attachment by mail, you just save it to look at it and > see what it is (a one-click, and expected-safe operation)
You do *WHAT*?
> but when it appears on the desktop background
Wait, not only do you deliberately save random unidentified email attachments, you save them to the DESKTOP?
Whatever is wrong with you, it's no little thing.
> What should happen:
What should happen, when you get an email attachment and you do not know what it is, is that you either ignore it, or if you have a certain morbid curiosity you maybe save it in/tmp and look at it in something that will treat it as random data (e.g., a hex editor) or use a file-magic utility to determine what kind of content it has in it.
Under no circumstances should an unidentified email attachment ever get anywhere near your desktop. If you don't understand this, maybe you should let your network administrator run that attachment stripper on the MTA like he keeps threatening to do every time he has to rebuild your workstation.
With that said, I do think.desktop files are an inherently bad idea, although they're pretty irrelevant to me since I don't even have nautilus in my session. It's a resource hog, and I never use it. I haven't had any desire to use a graphical file manager since I discovered tab completion sometime in the nineties. This does mean my background is a plain color instead of a pretty picture, but since I generally have a lot of windows open I never *see* much of the background anyway. Instead of icons on the desktop, I keep launchers on the left-side panel, and in drawers.
I bet you can think of some open-source projects that could use some server hardware. I'd pick ones whose software I personally use, if it were me. Let's see... I use Emacs and Gnus, so if it were me I'd probably ask the people in charge of those projects if they could use a couple of 1U servers. Oh, and Debian. And the OpenSSL/OpenSSH folks. I use Firefox a lot, but they've got enough money for their hardware needs, due to their deal with Google. Wikipedia's needs are too large for the small amount of hardware you're talking about to even matter, so skip them too. Does the Apache foundation need hardware, or are they pretty well taken care of? Oooh, what about the Perl dev team, or the CPAN folks? You get the idea.
I mean, if you've got a better use for the hardware, sure, do that. It's your hardware, after all. (Or does it still belong to the startup? You didn't say so, and it's in your garage, so I kind of assumed not...) But if it's going to end up just sitting in a garage until it's too obsolete to be worth anything, hey, why *not* donate it?
For my first project, I changed my own blood type. I now have blood type C, a previously non-existent alternative to A or B. Now the Red Cross never asks me to donate blood, since nobody else would be able to receive it!
> I guess exploring the aftermath of the Dominion War or giving a > real sendoff to the TNG crowd would have been much to ask for.
Doing a post-DS9 or post-Voyager movie would have been terribly anticlimactic, because of the way those series ended.
Doing another TNG movie, without Data, would be... problematic. It either would have had to be touchy-feely all about B4's development, which would make for a really lousy movie, or skip over it and write as if he's basically turned into the new Data already, which would feel like a terribly lame retcon, or else it would have to leave Data out almost entirely, which would be emotionally hard for a lot of the fanbase (and possibly for some of the cast as well).
Doing an Enterprise movie isn't a much better option. I mean, the show was cancelled for a reason.
What they *probably* should have done is just let the franchise rest for a few years until it felt like time to create a new (probably twenty-fifth-century) series. But they didn't want to do that. They wanted to make a Star Trek movie now, so they can, you know, make money on it.
Hence, prequel.
(My vote, when they do get ready to create a 25th-century series, would be for Star Trek: Galaxies, a series based on the development of a brand new type of drive that makes intergalactic travel possible, so they can get beyond the Milky Way and encounter a lot of non-humanoid life forms. But right now, with Enterprise having been cancelled only a couple of years ago, it's too soon. Let it go for a while, so the fans can get to the point where they're really aching for some new material again, like they were before TNG came out.)
> OK, Microsoft didn't write VMS, but they surely stole wholesale from it for NT
Umm, have you ever *used* VMS?
NT is more similar to Unix, or Linux, or Mac OS X, or BeOS for that matter, than any of the above is to VMS. VMS is *different*.
I'll give one very small example. You know how Unix uses forward slashes for path separators, and DOS uses backward ones, and NT can actually use either? Well, VMS doesn't use any single character as a path separator. A typical VMS pathname looks like this: SYS$FOO:[ils_exec.web.opac]index.html;1 Yep, those periods inside the brackets are separating directories, but the brackets are separating the thing that tells which filesystem from the directories, and the directories from the filename. In the filename, the period is just a regular character, but the semicolon separates the filename from the version number. And then there's the dollar sign, but VMS environment variables are a whole nother topic.
Playing Blu-Ray disks is not normal in the Windows world, or any other world. I've never even *seen* a Blu-Ray disc. I see DVDs constantly -- shelved a whole bunch of them yesterday, in fact. But I've never seen a Blu-Ray disc. I've never seen a computer with the drive for them either. I know they exist, but the people who have them at this point are very firmly in the early adopter camp. Normal people are still getting used to DVDs and small Flash-based USB Mass Storage devices.
Not that it wouldn't be good to have open-source player software for Blu-Ray. It would, if nothing else because a lot of open-source users are early adopters. But it's not exactly a mainstream concern yet. Opening.docx files, just for instance, is a much more common need. (OOo 3.0 can do this, but a comment upthread said that Lenny doesn't ship with OOo 3 at this point.)
You know, that's funny, almost every time I hear of Photoshop, it's because somebody's comparing Gimp to it.
I have a friend who works in the publishing industry. (Among other things, he typesets ancient languages, such as Akkadian. He also creates a lot of book covers.) He's used Photoshop regularly for years. He told me a couple of years ago that he had heard about Gimp and tried it out, and was impressed with a really useful feature it had, that Photoshop lacked at the time. Then a month or so later a new version of Photoshop came out, and it had it, in spades. On the whole, he likes Photoshop better. But to me his comment suggests that the two are, indeed, comparable.
Personally, I like Gimp on account of how I'm used to it. Although 2.6 has been annoying me, in that I'm having difficulty getting used to the way they've rearranged the menus (particularly, making Colors a toplevel item). Objectively, I have to admit that the new arrangement is ultimately better, but darnit, I'm not *used* to it yet, and I keep reaching for Layer->Colors and it's NOT THERE, and that bugs me. Old habits are hard to break, and all that.
It's hard for me to compare Photoshop to Gimp, because I haven't seen a recent version of Photoshop. The last time I did see it, it was running on MacOS 8. And the interface was pretty terrible, e.g., it wouldn't always let you save in the image format you wanted, and did not tell you why. EVENTUALLY I figured out that it wanted me to flatten the image (i.e., merge visible layers) first. What? WHY? Gimp has NEVER required that. There were other major usability guffs too. But that was years ago, so the new version's presumably better. I mean, back then Gimp didn't show the menubar on image windows, so you had to use context menus for everything, and *that's* since been fixed.
Actually, etch was quick as Debian released go. Caught me completely by surprise coming out so soon. I didn't know Debian could do them that fast, or would choose to if they could.
> Sarge really was the source of these endless jokes.
Actually, long before sarge development began, or woody for that matter, there were already jokes about Debian releases being aeons and aeons apart and severely out of date. These jokes are probably almost as old as Debian itself. What happened with sarge is that the jokes went from lighthearted and fun to cruelly ruthless black comedy.
> > One would think so. After all, proprietary operating systems > > sometimes go twice that long between service packs. > But they aren't tied to the software they run so tightly.
Debian isn't that way because of anything Debian does wrong. It's that way because when application developers put out a new version of anything for Linux, they typically make it *require* the absolute latest version of every library it uses, which effectively means it won't run on an operating system that's more than a couple of months old.
It isn't just that there aren't ready-to-install packages. You can't install the latest Firefox on Debian etch even if you're willing to go to the trouble to compile it yourself, because it requires a newer version of GTK than the one in Debian. Bear in mind, GTK is the main widget set, the thing used to draw windows and scrollbars and checkboxes and so on in the graphical operating environment (Gnome). That's NOT something you're ever going to upgrade independently of the operating system (and even if you wanted to, you generally can't because the new version of GTK probably requires the absolute latest versions of twelve other things, and so on; when you get to the end of the chain, you probably find out that libc or something requires a more recent kernel than your system is based on). New versions of applications *SHOULD* support three-year-old versions of GTK. But they almost never do.
And if it's not GTK it's libc or glibc or some other basic part of the platform API. Again, new versions of applications *SHOULD* support three-year-old versions of these libraries, but the almost never do. I don't happen to know which library is (or which libraries are) the holdup for Subversion, but if it were possible to just compile it for etch, somebody would have done so, and the package would be available -- probably not from the official Debian etch repositories, but from backports or somewhere. If it's not available at all for Debian stable, it's almost certainly because it won't compile, because it requires a hyper-recent version of some library or another. And that's NOT the platform or distribution's fault. That's the application developer's fault.
Now, when the curmudgeonly sysadmin insists on running oldstable for months and months after the new stable release comes out, that's arguably a different matter. In that case, you don't necessarily expect new versions of application software to work. Although, on other platforms (e.g., Windows, or Mac OS X for that matter), you still would.
> A year and a half is an entirely reasonable amount of time to wait for an operating system release.
One would think so. After all, proprietary operating systems sometimes go twice that long between service packs.
But in the open-source world there's a different cultural paradigm around this issue. By the time a release is a year old, nothing new will run on it. If you want to use an operating system that has long dev cycles, like Debian (and yes, I'm currently typing this on etch), you end up with long stretches of time where the latest version of this or that application is not available to you, because it requires more recent versions of various libraries than you've got.
This isn't something the OS distributor can really fix. It's a cultural issue among the application developers. Nonetheless, it is the reality. I mean, I'm currently using Iceweasel 2.0.0.19. The Mozilla people have been yelling and screaming and wailing and gnashing their teeth for just months and months, bemoaning the fact that not everyone has updated to Firefox 3.x yet. But was Firefox 3.x available for Debian stable? It was not. If you should happen to want to use the latest version of Inkscape, or the latest version of OpenOffice.org, or the latest version of the Flash plugin if you're into that sort of thing... you can't.
Contrast this with the situation on other platforms. The most recent Microsoft operating system that won't run the current versions of all those applications I mentioned is Windows Me or, if you prefer to apply the Highlander Principle, Windows 98 SE. Windows XP has been out since, what, 2002? Granted it was insane to upgrade to it that early, but even if you waited for Service Pack 2, that's been out for a good long while now.
Why is it that the application developers can support a six-year-old proprietary operating system, but they aren't willing to support a less-than two-year-old OS distribution that's still the latest stable release?
First, you make the copyright notices in the source code all say "All Rights Reserved". This is what copyright law gives you by default anyway, but having the all-right-reserved notices makes it more clear to people who might not know all the nuances of copyright law, and I think it makes enforcement easier also.
Second, you include the source code with the binaries in the install, so that all the customers *have* the source code. They don't have any legal right or license to it, but they *have* it. This completely obviates any need for reverse-engineering.
As far as modification, you can just sort of informally tell the customers what kinds of modification they're allowed to do and still get tech support. (Since they're not allowed to do any distribution whatsoever, it wouldn't even make sense to do any legal enforcement against modification. The MOST you'd ever do is say "your modified configuration is unsupported" when the call tech support. So when you tell them what modifications they're allowed to do, you're really telling them what modifications you're willing to support.)
If you think a lot of the customers will want to share modifications, you should develop a policy on, and perhaps a forum for, sharing patches. ISTR that Minix allowed patch sharing, before it was relicensed as open-source software.
Where I come from, the primary meaning of "rabbit ears" has to do with being goofy when someone's trying to line you up for a stupid posed photograph, e.g., at a family reunion.
> the case for paying a monthly cable or satellite fee really does seem pretty weak these days
I can't imagine paying money for cable television. The only time I've ever had it was in the college dorm, where it was just part of the room-and-board package. Prior to that, I always assumed that the selection and quality of programming would be better than on broadcast television, and that there would be no commercials. I still wouldn't have wanted to pay a monthly bill for it, because after all it's still just television, but I assumed there was *some* value in it. These assumptions proved to be wrong. The selection and quality of programming is just as bad. There are a larger number of possible viewing times for any given program, but it's pretty much the same junk, more times per day. Do I really need to watch the same show eight different times on the same day? Exactly how bored do they think I am? (I suppose the intention is that you pick the time that's best for you. Apparently they've never heard of setting the VCR to tape something if you want to watch it at a different time. I could buy a VCR, or a DVR for that matter, for the cost of only a few months' worth of cable bills.) As for commercials, I was unable to detect any difference between broadcast and cable in that regard.
So, umm, why would I pay for cable tv? Because Time Warner says so? Meh. I completely fail to see value.
And that's assuming you do in fact want to watch television. Which, generally, I don't.
> If you want small and light, Firefox may no longer be the browser for you. All it need is an embedded emacs mode
It would probably be easier to clone Firefox *as* an Emacs major mode.
There are a couple of web browsers for Emacs already, of course, but they don't do nearly as good a job of rendering things as Gecko does. (Among other things, last I checked they didn't support images yet. Emacs only added image support fairly recently, in version 21 if I remember correctly, so not all of the software that runs in Emacs has quite caught up yet.) So it would be a fair amount of work to get anything up to the standards of what Firefox is.
But it would still probably be easier than trying to recreate Emacs within Firefox. Among other things, I don't think Firefox has good enough keyboard-input support primitives to really do everything that's needed, and XUL and Javascript *definitely* don't have the right data types (nor, for that matter, do C and C++), so you'd pretty much have to start from the ground floor, i.e., build a lisp interpreter first...
Have you seen IE8 yet? It's actually pretty good. Well, except for the UI, but as a web content developer I don't really care about IE's browser UI. (It's not like I'm going to use IE on my primary workstation, which runs Debian stable.) I'm mainly interested in how well it renders standard HTML and CSS. And from what I've seen so far, it's WAY ahead of IE7. It looks like I won't have to maintain a separate "legacy" stylesheet just for IE any more, once I drop IE7 support. That'll be nice.
On the other hand, in terms of correctly rendering standard HTML and CSS, I haven't really seen any significant improvements in Firefox, over its entire history. I'm sure there've been some, but for the most part they seem to have been relatively low-profile things that my (admittedly, usually fairly simple) HTML and CSS didn't trigger.
> They could refer to the company charter, which often has a phrase where the primary objective > of the company is "to maximize profits and increase shareholder value". If that is the case > for Microsoft (I have no reason to not think so here), the directors are violating a primary > tenant of their charter if they spend money frivolously.
Trying to show that eight billion for R&D is sufficiently frivolous to warrant corrective action could be something of an uphill battle.
This is Microsoft we're talking about here. They can *afford* eight billion a year for R&D. Now, if they were spending that eight billion on something that clearly would not produce value, such as using Oracle stock shares as toilet paper in the executive restrooms, that might be actionable. But research and development is generally considered important for company growth in most industries, and this is even more true in the software industry than in most others. Someone could possibly argue that they could maybe be getting by with an R&D budget of only seven billion, but it would also not be difficult to argue that as much cash as Microsoft is rolling in there really is no excuse not to be spending ten billion on R&D. Their revenue in 2008 was about sixty billion, more than fifteen billion of which is net income, and that's not an unusually good year for them, and almost all of the money comes from selling products that were developed as part of earlier R&D efforts. (They do also make some revenue from returns on various short-term investments, but the lion's share comes from selling software licenses.) "Where's the ROI?", the shareholder asks? Bad rhetoric. The ROI is obvious and considerable.
What the whiners are essentially saying is, "Screw the future of the company, give us all the money as dividends!" But that would be bad business.
Slashdot Mirror
> hell, Outlook has code to automatically execute attachments at the time they're received
Does it still? I thought they'd finally taken that out. (I think it does still make it entirely too easy for the user to launch executable attachments though.)
> *all* users, even sensible and cautious ones, can be easily tricked into running
.desktop files are an inherently bad idea, because there *ARE* a lot of users out there who fit the above description. But saying that all users would be infected, including sensible and cautious ones, is just plain idiotic. Users who practice safe and sane computing have absolutely nothing to fear from this, unless there's some kind of attack vector whereby an attacker can cause a malicious .desktop file to be saved to the user's desktop (or menus, or wherever), and frankly, if an attacker can cause arbitrary content to be written to your drive, then you've got much bigger problems than the .desktop files.
> an executable because the user interface makes it look exactly like an ordinary file.
No, not all users. Only users who deliberately save random unidentified garbage, and not only that but save it to their desktop, of all places, and then go along happily click-click-clicking all over it. In other words, people who are just plain not bright enough to be trusted with a complex task such as operating a computer.
I will grant you that
> If you expect people to figure out whether a file is safe before "launching/opening" it,
/dev/null and have done.
> then you are expecting people to solve something arguably harder than the "halting problem"
I think you've overstated that somewhat. If it came as an attachment to an email message, and you were not expecting to receive it, and you don't know what it is, and it's an _executable_ filetype, you generally don't need to know any more about it than that. Send it to
> The OS does not matter
Well, the OS is certainly not the only or even the primary factor in security. I don't know that I'd go so far as to say it doesn't matter at all.
> Viruses and Trojans require the user to not think and execute things willy-nilly.
Agreed, although in the case of an email attachment, a naively-designed mailreader greatly increases the likelihood that the user will do so. When a sane mailreader (e.g., Pegasus Mail) sees an attachment with a filetype or extension that suggests executable content, and the user tries to save the thing to the filesystem, the MUA presents a big fat scary dialog box with the phrase "VIRUS Warning" in the titlebar, the phrase "Possible VIRUS" in a bold header over the text that explains that the content is executable and potentially dangerous, and with the safe "No" option selected by default.
> Every regular use I have met that was infected simply clicked yes to every
> dialog box they did not want to bother reading and understanding.
It used to be possible to get infected without taking any special action, if you used a certain extremely insecure mailreader whose initials are MSOE and received a dangerous attachment. I *think* this has been cleaned up somewhat now, although of course the users can still launch dangerous attachments if they choose to do so (and I believe it actually lets the user directly *launch* the thing, not just save it).
> You get an attachment by mail, you just save it to look at it and
/tmp and look at it in something that will treat it as random data (e.g., a hex editor) or use a file-magic utility to determine what kind of content it has in it.
.desktop files are an inherently bad idea, although they're pretty irrelevant to me since I don't even have nautilus in my session. It's a resource hog, and I never use it. I haven't had any desire to use a graphical file manager since I discovered tab completion sometime in the nineties. This does mean my background is a plain color instead of a pretty picture, but since I generally have a lot of windows open I never *see* much of the background anyway. Instead of icons on the desktop, I keep launchers on the left-side panel, and in drawers.
> see what it is (a one-click, and expected-safe operation)
You do *WHAT*?
> but when it appears on the desktop background
Wait, not only do you deliberately save random unidentified email attachments, you save them to the DESKTOP?
Whatever is wrong with you, it's no little thing.
> What should happen:
What should happen, when you get an email attachment and you do not know what it is, is that you either ignore it, or if you have a certain morbid curiosity you maybe save it in
Under no circumstances should an unidentified email attachment ever get anywhere near your desktop. If you don't understand this, maybe you should let your network administrator run that attachment stripper on the MTA like he keeps threatening to do every time he has to rebuild your workstation.
With that said, I do think
I bet you can think of some open-source projects that could use some server hardware. I'd pick ones whose software I personally use, if it were me. Let's see... I use Emacs and Gnus, so if it were me I'd probably ask the people in charge of those projects if they could use a couple of 1U servers. Oh, and Debian. And the OpenSSL/OpenSSH folks. I use Firefox a lot, but they've got enough money for their hardware needs, due to their deal with Google. Wikipedia's needs are too large for the small amount of hardware you're talking about to even matter, so skip them too. Does the Apache foundation need hardware, or are they pretty well taken care of? Oooh, what about the Perl dev team, or the CPAN folks? You get the idea.
I mean, if you've got a better use for the hardware, sure, do that. It's your hardware, after all. (Or does it still belong to the startup? You didn't say so, and it's in your garage, so I kind of assumed not...) But if it's going to end up just sitting in a garage until it's too obsolete to be worth anything, hey, why *not* donate it?
For my first project, I changed my own blood type. I now have blood type C, a previously non-existent alternative to A or B. Now the Red Cross never asks me to donate blood, since nobody else would be able to receive it!
> I guess exploring the aftermath of the Dominion War or giving a
> real sendoff to the TNG crowd would have been much to ask for.
Doing a post-DS9 or post-Voyager movie would have been terribly anticlimactic, because of the way those series ended.
Doing another TNG movie, without Data, would be... problematic. It either would have had to be touchy-feely all about B4's development, which would make for a really lousy movie, or skip over it and write as if he's basically turned into the new Data already, which would feel like a terribly lame retcon, or else it would have to leave Data out almost entirely, which would be emotionally hard for a lot of the fanbase (and possibly for some of the cast as well).
Doing an Enterprise movie isn't a much better option. I mean, the show was cancelled for a reason.
What they *probably* should have done is just let the franchise rest for a few years until it felt like time to create a new (probably twenty-fifth-century) series. But they didn't want to do that. They wanted to make a Star Trek movie now, so they can, you know, make money on it.
Hence, prequel.
(My vote, when they do get ready to create a 25th-century series, would be for Star Trek: Galaxies, a series based on the development of a brand new type of drive that makes intergalactic travel possible, so they can get beyond the Milky Way and encounter a lot of non-humanoid life forms. But right now, with Enterprise having been cancelled only a couple of years ago, it's too soon. Let it go for a while, so the fans can get to the point where they're really aching for some new material again, like they were before TNG came out.)
> OK, Microsoft didn't write VMS, but they surely stole wholesale from it for NT
Umm, have you ever *used* VMS?
NT is more similar to Unix, or Linux, or Mac OS X, or BeOS for that matter, than any of the above is to VMS. VMS is *different*.
I'll give one very small example. You know how Unix uses forward slashes for path separators, and DOS uses backward ones, and NT can actually use either? Well, VMS doesn't use any single character as a path separator. A typical VMS pathname looks like this: SYS$FOO:[ils_exec.web.opac]index.html;1 Yep, those periods inside the brackets are separating directories, but the brackets are separating the thing that tells which filesystem from the directories, and the directories from the filename. In the filename, the period is just a regular character, but the semicolon separates the filename from the version number. And then there's the dollar sign, but VMS environment variables are a whole nother topic.
Playing Blu-Ray disks is not normal in the Windows world, or any other world. I've never even *seen* a Blu-Ray disc. I see DVDs constantly -- shelved a whole bunch of them yesterday, in fact. But I've never seen a Blu-Ray disc. I've never seen a computer with the drive for them either. I know they exist, but the people who have them at this point are very firmly in the early adopter camp. Normal people are still getting used to DVDs and small Flash-based USB Mass Storage devices.
.docx files, just for instance, is a much more common need. (OOo 3.0 can do this, but a comment upthread said that Lenny doesn't ship with OOo 3 at this point.)
Not that it wouldn't be good to have open-source player software for Blu-Ray. It would, if nothing else because a lot of open-source users are early adopters. But it's not exactly a mainstream concern yet. Opening
Meh. I'm not much of a gamer, so I don't care about DNF. I was kind of hoping Perl6 would be the next big software release in the news...
> GIMP doesn't even compare to Photoshop.
You know, that's funny, almost every time I hear of Photoshop, it's because somebody's comparing Gimp to it.
I have a friend who works in the publishing industry. (Among other things, he typesets ancient languages, such as Akkadian. He also creates a lot of book covers.) He's used Photoshop regularly for years. He told me a couple of years ago that he had heard about Gimp and tried it out, and was impressed with a really useful feature it had, that Photoshop lacked at the time. Then a month or so later a new version of Photoshop came out, and it had it, in spades. On the whole, he likes Photoshop better. But to me his comment suggests that the two are, indeed, comparable.
Personally, I like Gimp on account of how I'm used to it. Although 2.6 has been annoying me, in that I'm having difficulty getting used to the way they've rearranged the menus (particularly, making Colors a toplevel item). Objectively, I have to admit that the new arrangement is ultimately better, but darnit, I'm not *used* to it yet, and I keep reaching for Layer->Colors and it's NOT THERE, and that bugs me. Old habits are hard to break, and all that.
It's hard for me to compare Photoshop to Gimp, because I haven't seen a recent version of Photoshop. The last time I did see it, it was running on MacOS 8. And the interface was pretty terrible, e.g., it wouldn't always let you save in the image format you wanted, and did not tell you why. EVENTUALLY I figured out that it wanted me to flatten the image (i.e., merge visible layers) first. What? WHY? Gimp has NEVER required that. There were other major usability guffs too. But that was years ago, so the new version's presumably better. I mean, back then Gimp didn't show the menubar on image windows, so you had to use context menus for everything, and *that's* since been fixed.
Actually, etch was quick as Debian released go. Caught me completely by surprise coming out so soon. I didn't know Debian could do them that fast, or would choose to if they could.
> Sarge really was the source of these endless jokes.
Actually, long before sarge development began, or woody for that matter, there were already jokes about Debian releases being aeons and aeons apart and severely out of date. These jokes are probably almost as old as Debian itself. What happened with sarge is that the jokes went from lighthearted and fun to cruelly ruthless black comedy.
> > One would think so. After all, proprietary operating systems
> > sometimes go twice that long between service packs.
> But they aren't tied to the software they run so tightly.
Debian isn't that way because of anything Debian does wrong. It's that way because when application developers put out a new version of anything for Linux, they typically make it *require* the absolute latest version of every library it uses, which effectively means it won't run on an operating system that's more than a couple of months old.
It isn't just that there aren't ready-to-install packages. You can't install the latest Firefox on Debian etch even if you're willing to go to the trouble to compile it yourself, because it requires a newer version of GTK than the one in Debian. Bear in mind, GTK is the main widget set, the thing used to draw windows and scrollbars and checkboxes and so on in the graphical operating environment (Gnome). That's NOT something you're ever going to upgrade independently of the operating system (and even if you wanted to, you generally can't because the new version of GTK probably requires the absolute latest versions of twelve other things, and so on; when you get to the end of the chain, you probably find out that libc or something requires a more recent kernel than your system is based on). New versions of applications *SHOULD* support three-year-old versions of GTK. But they almost never do.
And if it's not GTK it's libc or glibc or some other basic part of the platform API. Again, new versions of applications *SHOULD* support three-year-old versions of these libraries, but the almost never do. I don't happen to know which library is (or which libraries are) the holdup for Subversion, but if it were possible to just compile it for etch, somebody would have done so, and the package would be available -- probably not from the official Debian etch repositories, but from backports or somewhere. If it's not available at all for Debian stable, it's almost certainly because it won't compile, because it requires a hyper-recent version of some library or another. And that's NOT the platform or distribution's fault. That's the application developer's fault.
Now, when the curmudgeonly sysadmin insists on running oldstable for months and months after the new stable release comes out, that's arguably a different matter. In that case, you don't necessarily expect new versions of application software to work. Although, on other platforms (e.g., Windows, or Mac OS X for that matter), you still would.
> A year and a half is an entirely reasonable amount of time to wait for an operating system release.
One would think so. After all, proprietary operating systems sometimes go twice that long between service packs.
But in the open-source world there's a different cultural paradigm around this issue. By the time a release is a year old, nothing new will run on it. If you want to use an operating system that has long dev cycles, like Debian (and yes, I'm currently typing this on etch), you end up with long stretches of time where the latest version of this or that application is not available to you, because it requires more recent versions of various libraries than you've got.
This isn't something the OS distributor can really fix. It's a cultural issue among the application developers. Nonetheless, it is the reality. I mean, I'm currently using Iceweasel 2.0.0.19. The Mozilla people have been yelling and screaming and wailing and gnashing their teeth for just months and months, bemoaning the fact that not everyone has updated to Firefox 3.x yet. But was Firefox 3.x available for Debian stable? It was not. If you should happen to want to use the latest version of Inkscape, or the latest version of OpenOffice.org, or the latest version of the Flash plugin if you're into that sort of thing... you can't.
Contrast this with the situation on other platforms. The most recent Microsoft operating system that won't run the current versions of all those applications I mentioned is Windows Me or, if you prefer to apply the Highlander Principle, Windows 98 SE. Windows XP has been out since, what, 2002? Granted it was insane to upgrade to it that early, but even if you waited for Service Pack 2, that's been out for a good long while now.
Why is it that the application developers can support a six-year-old proprietary operating system, but they aren't willing to support a less-than two-year-old OS distribution that's still the latest stable release?
First, you make the copyright notices in the source code all say "All Rights Reserved". This is what copyright law gives you by default anyway, but having the all-right-reserved notices makes it more clear to people who might not know all the nuances of copyright law, and I think it makes enforcement easier also.
Second, you include the source code with the binaries in the install, so that all the customers *have* the source code. They don't have any legal right or license to it, but they *have* it. This completely obviates any need for reverse-engineering.
As far as modification, you can just sort of informally tell the customers what kinds of modification they're allowed to do and still get tech support. (Since they're not allowed to do any distribution whatsoever, it wouldn't even make sense to do any legal enforcement against modification. The MOST you'd ever do is say "your modified configuration is unsupported" when the call tech support. So when you tell them what modifications they're allowed to do, you're really telling them what modifications you're willing to support.)
If you think a lot of the customers will want to share modifications, you should develop a policy on, and perhaps a forum for, sharing patches. ISTR that Minix allowed patch sharing, before it was relicensed as open-source software.
Where I come from, the primary meaning of "rabbit ears" has to do with being goofy when someone's trying to line you up for a stupid posed photograph, e.g., at a family reunion.
> the case for paying a monthly cable or satellite fee really does seem pretty weak these days
I can't imagine paying money for cable television. The only time I've ever had it was in the college dorm, where it was just part of the room-and-board package. Prior to that, I always assumed that the selection and quality of programming would be better than on broadcast television, and that there would be no commercials. I still wouldn't have wanted to pay a monthly bill for it, because after all it's still just television, but I assumed there was *some* value in it. These assumptions proved to be wrong. The selection and quality of programming is just as bad. There are a larger number of possible viewing times for any given program, but it's pretty much the same junk, more times per day. Do I really need to watch the same show eight different times on the same day? Exactly how bored do they think I am? (I suppose the intention is that you pick the time that's best for you. Apparently they've never heard of setting the VCR to tape something if you want to watch it at a different time. I could buy a VCR, or a DVR for that matter, for the cost of only a few months' worth of cable bills.) As for commercials, I was unable to detect any difference between broadcast and cable in that regard.
So, umm, why would I pay for cable tv? Because Time Warner says so? Meh. I completely fail to see value.
And that's assuming you do in fact want to watch television. Which, generally, I don't.
However will the city government function without this important resource?
Seriously, you know this story is for real because nobody would think to make up something so bizarre.
Won't Microsoft revoke their OEM licensing agreements or something?
> If you want small and light, Firefox may no longer be the browser for you. All it need is an embedded emacs mode
It would probably be easier to clone Firefox *as* an Emacs major mode.
There are a couple of web browsers for Emacs already, of course, but they don't do nearly as good a job of rendering things as Gecko does. (Among other things, last I checked they didn't support images yet. Emacs only added image support fairly recently, in version 21 if I remember correctly, so not all of the software that runs in Emacs has quite caught up yet.) So it would be a fair amount of work to get anything up to the standards of what Firefox is.
But it would still probably be easier than trying to recreate Emacs within Firefox. Among other things, I don't think Firefox has good enough keyboard-input support primitives to really do everything that's needed, and XUL and Javascript *definitely* don't have the right data types (nor, for that matter, do C and C++), so you'd pretty much have to start from the ground floor, i.e., build a lisp interpreter first...
Speaking of IE7 being better than IE6...
Have you seen IE8 yet? It's actually pretty good. Well, except for the UI, but as a web content developer I don't really care about IE's browser UI. (It's not like I'm going to use IE on my primary workstation, which runs Debian stable.) I'm mainly interested in how well it renders standard HTML and CSS. And from what I've seen so far, it's WAY ahead of IE7. It looks like I won't have to maintain a separate "legacy" stylesheet just for IE any more, once I drop IE7 support. That'll be nice.
On the other hand, in terms of correctly rendering standard HTML and CSS, I haven't really seen any significant improvements in Firefox, over its entire history. I'm sure there've been some, but for the most part they seem to have been relatively low-profile things that my (admittedly, usually fairly simple) HTML and CSS didn't trigger.
> How about: "show me where the prime minister's house is on a map"?
I'm sorry, I can't do that. Would you like to see some pictures of interesting plants or animals?
> They could refer to the company charter, which often has a phrase where the primary objective
> of the company is "to maximize profits and increase shareholder value". If that is the case
> for Microsoft (I have no reason to not think so here), the directors are violating a primary
> tenant of their charter if they spend money frivolously.
Trying to show that eight billion for R&D is sufficiently frivolous to warrant corrective action could be something of an uphill battle.
This is Microsoft we're talking about here. They can *afford* eight billion a year for R&D. Now, if they were spending that eight billion on something that clearly would not produce value, such as using Oracle stock shares as toilet paper in the executive restrooms, that might be actionable. But research and development is generally considered important for company growth in most industries, and this is even more true in the software industry than in most others. Someone could possibly argue that they could maybe be getting by with an R&D budget of only seven billion, but it would also not be difficult to argue that as much cash as Microsoft is rolling in there really is no excuse not to be spending ten billion on R&D. Their revenue in 2008 was about sixty billion, more than fifteen billion of which is net income, and that's not an unusually good year for them, and almost all of the money comes from selling products that were developed as part of earlier R&D efforts. (They do also make some revenue from returns on various short-term investments, but the lion's share comes from selling software licenses.) "Where's the ROI?", the shareholder asks? Bad rhetoric. The ROI is obvious and considerable.
What the whiners are essentially saying is, "Screw the future of the company, give us all the money as dividends!" But that would be bad business.