First, they will have to show that this code is their property; as others have mentioned, both Linux and SCO Unix contain BSD code - which is perfectly legal to copy.
Second, if the code is stuff from IBM/Sequent, they will need to show that IBM did not in fact have the right to give the code away to Linux. This will not be determined until the lawsuit is settled (and looks unlikely to go in SCO:s favour considering the side agreements that explicitly give IBM permission to do whatever they want with their code).
And don't forget that in the case that IBM loses that suit, it becomes a matter between SCO and IBM only. That code IP is owned by IBM, not SCO, no matter what, and Linux users are free to continue using it. The only one damaged by that would be IBM, as they would be found for breach of contract.
Oh, and the 110/2000/890000/dozens/whatever number sco is flinging around at the moment is pretty much immaterial. They haven't exactly been paragons of accuracy in this affair so far.
Again, to reiterate, the whole "illegaly copied code" is, so far, just smoke and mirrors. There is no lawsuit alleging any copyright infringement. There is only a lawsuit alleging that IBM violated an agreement not to share some of their IP with third parties.
Except that companies want to shed employees when _they_ want to, not when the employee does. They want to kick people out when the project is complete. They don't want to the employee to leave in the middle of the project due to stress and suffering personal life.
My experience as a Ph.D. (though in cognitive science and robotics, not computer science) is that you do tend to become disqualified for some kinds of work. Essentially, grunt work programming, run-of-the-mill system administration and so on will be pretty much off-limits to you.
There are three reasons, generally, for this: first, you spent years in school whereas your peers went out and got work experience (or just learned a lot about unemployment benefits), so you will compete with people that have experience, whereas you do not. Second, your prospective employer will fear that you will want a higher salary (or other benefits) due to your degree, and they won't want to hire you when they can get a cheaper programmer that can do the job just as well. Third, they will (rightly) suspect that you will not find the work stimulating, rewarding or career-enhancing enough, leaving them with the need to do the hiring process all over again in six months or a year.
That said, a Ph.D. opens up whole new career paths that you really aren't qualified for otherwise. You of course have the research and teaching career path sort-of-open (though that is for masochists only, the way academia is going). You are also suddenly eligible to pursue an R&D career in big corporations. Last (but not least), the added knowledge and insights you get, the contact network (especially if you do a post-doc as well) and the skill you get in doing research means it is feasible to go out on your own with your own company R&D-oriented company (alone or with colleagues).
So, you lose some opportunities at the lower end, but gain some at the top. Of course, doing a Ph.D. is also a lot of fun (at least afterwards:) ). It's your call.
True, OO conversion filters aren't perfect - but neither are the Word conversion filters. Moving documents between different versions is a pain, and a big one.
What's worse, the older the document is, the more problems you get: Say you wrote a complex document in an older version of word, Version A. Since then, you have had version B and version C. B can convert your document seemingly without problems. C can convert an extremely similar document (same formatting, different text) from B just fine. But C will make an unholy mess of thedocument B has converted from A.
With these kind of issues, how can an organization actually guarantee that their ten year old docs can still be used, when they have them stored in Word "format"? No matter what application you use for document editing, you should never use the Word formats to store them, it's just too messy and too risky.
Nah. A result is a result no matter what methods were used to produce it. No cheating.
That said, there are arguments in favour of a classical proof as well. First, of course, is the matter of elegance; an elegant symbolic proof is a lot more pleasing than a brute-force approach (though an inelegant symbolic proof is as bad - or worse - than a method like this).
Second, a theoretical proof is sometimes more interesting for the secondary results it produces and the new avenues of progress in other areas, rather than in the proof itself. This is generally lacking for brute-force methods.
But in reality, these methods complement each other quite nicely. Knowing what the result should be, making an elegant classical proof of it becomes so much easier than before. And of course, you tend to need to know quite a lot about a problem (culled from classical methods) before you can formulate a prq'acticable brute-force approach.
I have seen this effect as well, among my friends that has gone to Linux from Windows. 6 out of 8 have ended up running Gnome over KDE, and this is one of the reasons for many of them. They typically dual-boot and/or use Windows at work, and they feel KDE to be clumsy, simply because they mix them up at the "fingertip" level and thus get the impression that things do not work well.
On the upside, this effect seems to go the other way as well; their opinion of Windows really took a dive during the first months of Linux use.
Basically, the reason is that to be effective in any desktop, people rapidly learn reflexive mappings between what they see and what to do, to achieve a certain, desired, outcome. With two desktops that are very similar (but not identical) to each other, what they see is similar enough that it triggers responses for the wrong desktop. Also, when the actions needed are very similar (but not identical) you get interference in learning the correct actions.
In the end, it seems the spartan UI of Gnome is both different enough, and easy enough to map as above, to make for a very quick transition. Apart from this, most also are fairly relieved with the sparseness; comments like "it's so clean", and "it's easy to find what I want" are common.
Don't forget that the vast majority of computer users are like the majority of car owners: it's a tool. A good tool, a tool you easily can become attached to, but a tool nonetheless. We who frequent places like slashdot are really the computing equivalent of hotrodders. Nice hobby, but you would never build a mainstream car based on their preferences.
Python, Perl and Ruby are all very good interpreted, flexible, rapid-prototyping languages. They all have their relative strengths and weaknesses, but all are good enough that if you are choosing between them, it boils down pretty much to your own preferences and what coworkers and other people around you use (or on what animal you prefer on the cover of your reference literature:) ).
If you mean this class of languages as opposed to C, C++, Java and so on, well, it becomes a matter of what you want to accomplish. The great benefits of these interpreted languages are that they make development very fast, compared to the more traditional languages (yes, Java is interpreted, but it is still designed as a traditional language). You spend more time solving your task and less time managing the mechanics of development. Also, they really make use of the benefits of being interpreted with things like closures, dynamic code evaluation and so on. And they typically have very complete, transparent access to the surrounding system - why spend two days writing some hairy functionality when you can trivially filter your data through an external application that already does the whole job for you? Do not underestimate "scripting type glue".
They do make a pretty good fit running large systems - the Swedish pension management system is all written in Perl, for instance, and Zope is written in Python. They are also quite efficient; they are on the whole as fast as a Java implementation, and occasionally (when the task plays to the specific language's strengths), quite a bit faster.
I typically use C/C++ and Perl for development, and every time I've been using Perl for a while, I get bouts of frustration with traditional languages for the lack of such things as hash datatypes and inline regular expressions. But for some tasks, traditional languages are the way to go.
An interesting twist is that is this ridiculous line of reasoning would stand, it means the BSD license is invalid too (and all that code reverts to the original copyright holder). Now, a lot of products from a lot of companies contains BSD-licensed code (MS uses BSD code in their network layer, for example). In essence, this could bring the entire IT insdustry to a screeching halt for the next five years while everybody figures out who owns what and sues each others bankrupt carcasses over it.
As the other poster here said, there is a six-month development cycle implemented - which really has increased speed of development.
Consider that first waiting for GTK 2.4 (a month or so), another possible month for GTK 2.4.1 (if there are any ooops:es in the 2,4 release), and another month to make sure gnome is stabilized wrt GTK. You are just a month from the next release freeze by then. And with such a long wait, you would inevitably break code freeze, or have a lot of frustrated developers on your hands.
With the current schedule, GNOME will have four months to get properly integrated with GTK 2.4, rather than hurrying it up over a month or so to get a release out the door.
Heh. I run on a hi-res laptop (1400x1050), so changing resolutions is not really a solution (tends to blur the image, as it needs to interpolate). Just upping the default text size works fine for me, though.
It's because 2.3.5 is a _development_ release. It is not intended for end-users, but for developers (which, presumably, aren't too fazed with the task). This is a preview of the 2.4 release which will happen in a few weeks.
* It does take up less, I believe (not having done any formal comparison).
* I have never seen that problem; maybe time for a bug report?
* That is Redhat, and can be turned off. Go to "Preferences" -> "CD properties".
* It won't really release all memory until you _really_ close it - as long as you want it to handle your desktop it is still running. Oh, and just like all other Linux apps, releasing memory doesn't actually release the memory as such; the pages are kept around as long as nothing else needs it, and they are still mapped to the app as long as the app is running. Looking at RSS gives you a sort-of reasonable estimate on the memory use, but it too (if I am correct) will overestimate memory use.
So long as HTML mail can be sent, it will be sent, and it will be used for spam--and for other things as well....and it will be dumped into my spam folder, spam or not. Sure, I look thorugh that folder a couple of times a week before emptying it, so chances are decent that a non-spam mail will be noticed and read by me. If not, tough. Same thing with mail from Hotmail, Yahoo or MSN. If it was really important, you can send it again, or call me.
As I stated in another comment, that "ugly hack" type comment was entered in jest, and the story submitter chose to interpret it differently.
One reason Gnome people haven't been in any real hurry, I think, is that a lot use gkrellm, which sort of does the same thing. The Karamba people decided something better was needed and implemented their thing. Now some Gnome people find that Karamba is sweet, and does something similar in turn for Gnome (but with the great benefit of hindsight from how Karamba is used). No doubt some KDE people will learn from gDesklets and make something even better.
A developer calls it "an ugly hack". Well, not quite. It was pretty clearly marked as tongue-in-cheek, and not to be taken seriously.
Looks to me like the submitter deliberately wants to fan any remaining flames between the projects; who knows why.
Instead, we have some pretty good illustrations as to why having two projects is a really good idea. KDE gets Karamba (and SuperKaramba) which takes off like wildfire. Undaunted, some Gnome people sit down and look at what Karamba does and learns from it (what the devels envisioned versus how it is actually being used; awkwardness and mistakes in teh design) and develop something similar, but with the benefir of hindsight from the other project. No doubt will the Karamba people look at gDesklets and in turn learn from it's strengths and weaknesses. THe end result is a set of tools that become far better, faster, than either would have become on its own.
Sure - if it's as simple as finding info about Euclid's algorithm.
If I want to find all texts about LTP in the amygdala, however, flipping through a dozen books and a few hundred papers just isn't the same as a quick "grep". If I want to find the source of a half-remembered quotation, I'd have to spend days to find where I read it - or spend half my reading time filling in index cards and keeping them sorted, which is what people had to do before their texts were searchable. If you want to do that, you are welcome to.
Laptop: I do have the books in paper format as well. And the size of the laptop compared to books is a non-issue; it's not laptops OR books, it's laptop, or laptop AND books.
Oh, and for all the convenience of generating vaiorus formats, you _still_ occasionally bump into PDF:s that are simply scanned pages, or where you can't extract the text for some other reason.
BTW, the title turned out wrong - Phoenix autocompleted it without me noticing it...:/
I download quite a lot of books. Now, most (if not all) are books I already own; this goes for fiction as well as non-fiction. I have also considered getting a scanner and OCR software to scan all those books I don't already have in machine-readable form (no good OCR scanning software for Linux as far as I've been able to tell, though). I also have several directories filled with papers downloaded from databases or from the authors' homepages.
So, if I already own the books, and books are nicer to read on paper (and they are), why have them? Convenience. Say you are going on a two-week trip. You could bring one, maybe two, books with you before it gets cumbersome. If I have my laptop with me, on the other hand, I have more or less my entire library available. This is great, both for having reference litterature with me, and for whiling away a few hours with a novel in some hotel.
The benefit is not only when traveling either. WHerever and whenever I have my computer, my books travel along. And they are searchable - this is absolutely invaluable.
A small note to other researchers: if you are putting up your papers for download, would you _please_ not just have them as PDF:s of scanned images of the pages in the paper?! They become utterly opaque to searching and indexing, and when I search through my collection for relevant stuff, I will miss your paper and you will miss a citation.
I mean, if you have a nautilus window open on an ordinary directory; or of you have a shell open in that directory, the system will silently allow you to delete the directory and it's contents without complaining about other processes still accessing it. I don't see why this should be treated differently from an UI point of view?
But a basic problem is that you aren't reminded _what_ resource is holding the disk and why.
You just get a terse message that something is using it. It could be you're burning a CD, sure, but it could also just be that you've forgotten that you have a shell open in the directory somewhere, in a non-visible tab in a terminal - possibly hiding behind an application window - on one of your workspaces.
Yes, if something is queuing for reading or writing the device, I agree, unmounting it should be prevented. If all there is is an open file descriptor (which it is 99% of the time), then it should probably protest, but allow me to just unmount the media if I insist, without me having to hunt through the system in search for whatever I (or a process I started) have left behind.
I recently bought this, and for much the same reasons as the reviewer.
Basically, if your introduction to Perl was via "Learning Perl" then this is probably a great next step. I went through the Camel book and the Perl cookbook instead, and find that this one does not give all that much more information as I would have liked. This is not strange; the authors explicitly say in the preface that this is the companion book to "Learning Perl".
On the upside, it does give a good deal of useful snippets of info, and it manages to give clear explanations for some stuff that is otherwise quite opaque; the way it explains the Perl object model, for example is much clearer to me than the treatment given in the Camel book.
I would have given it 7.5-8 rather than the extreme score the reviewer gave.
There is something called "due diligence". They are an operating systems company. They pinned a large part of their business on their Linux distribution, and did so for a couple of years. They even continued offering their distribution under GPL for a couple of months after they started trying to assert that their IP was in the kernel.
There can be a case for saying that given their area of expertise, and the importance of this component to their operations, they could reasonably be expected to know what they were selling.
Slashdot Mirror
Um, again, no.
A finding in favour of SCO would _only_ mean a breach of contract between IBM and SCO - it does not transfer any IP rights to SCO.
As I said, the allegation that the code in question is actually SCO:s have not been made in any suit. It is not part of the SCO-IBM suit.
Besides, as comments elsewhere show, it seems that what they've displayed here is not owned by SCO in any case, and is long since public code.
Um, no, that is a very premature conclusion.
First, they will have to show that this code is their property; as others have mentioned, both Linux and SCO Unix contain BSD code - which is perfectly legal to copy.
Second, if the code is stuff from IBM/Sequent, they will need to show that IBM did not in fact have the right to give the code away to Linux. This will not be determined until the lawsuit is settled (and looks unlikely to go in SCO:s favour considering the side agreements that explicitly give IBM permission to do whatever they want with their code).
And don't forget that in the case that IBM loses that suit, it becomes a matter between SCO and IBM only. That code IP is owned by IBM, not SCO, no matter what, and Linux users are free to continue using it. The only one damaged by that would be IBM, as they would be found for breach of contract.
Oh, and the 110/2000/890000/dozens/whatever number sco is flinging around at the moment is pretty much immaterial. They haven't exactly been paragons of accuracy in this affair so far.
Again, to reiterate, the whole "illegaly copied code" is, so far, just smoke and mirrors. There is no lawsuit alleging any copyright infringement. There is only a lawsuit alleging that IBM violated an agreement not to share some of their IP with third parties.
Except that companies want to shed employees when _they_ want to, not when the employee does. They want to kick people out when the project is complete. They don't want to the employee to leave in the middle of the project due to stress and suffering personal life.
My experience as a Ph.D. (though in cognitive science and robotics, not computer science) is that you do tend to become disqualified for some kinds of work. Essentially, grunt work programming, run-of-the-mill system administration and so on will be pretty much off-limits to you.
:) ). It's your call.
There are three reasons, generally, for this: first, you spent years in school whereas your peers went out and got work experience (or just learned a lot about unemployment benefits), so you will compete with people that have experience, whereas you do not. Second, your prospective employer will fear that you will want a higher salary (or other benefits) due to your degree, and they won't want to hire you when they can get a cheaper programmer that can do the job just as well. Third, they will (rightly) suspect that you will not find the work stimulating, rewarding or career-enhancing enough, leaving them with the need to do the hiring process all over again in six months or a year.
That said, a Ph.D. opens up whole new career paths that you really aren't qualified for otherwise. You of course have the research and teaching career path sort-of-open (though that is for masochists only, the way academia is going). You are also suddenly eligible to pursue an R&D career in big corporations. Last (but not least), the added knowledge and insights you get, the contact network (especially if you do a post-doc as well) and the skill you get in doing research means it is feasible to go out on your own with your own company R&D-oriented company (alone or with colleagues).
So, you lose some opportunities at the lower end, but gain some at the top. Of course, doing a Ph.D. is also a lot of fun (at least afterwards
True, OO conversion filters aren't perfect - but neither are the Word conversion filters. Moving documents between different versions is a pain, and a big one.
What's worse, the older the document is, the more problems you get: Say you wrote a complex document in an older version of word, Version A. Since then, you have had version B and version C. B can convert your document seemingly without problems. C can convert an extremely similar document (same formatting, different text) from B just fine. But C will make an unholy mess of thedocument B has converted from A.
With these kind of issues, how can an organization actually guarantee that their ten year old docs can still be used, when they have them stored in Word "format"? No matter what application you use for document editing, you should never use the Word formats to store them, it's just too messy and too risky.
But how do you know MS WORD doesn't contain emacs code ;-)
:)
Because an MS Word install just isn't large enough.
As a Vim user, I just couldn't resist - sorry.
Nah. A result is a result no matter what methods were used to produce it. No cheating.
That said, there are arguments in favour of a classical proof as well. First, of course, is the matter of elegance; an elegant symbolic proof is a lot more pleasing than a brute-force approach (though an inelegant symbolic proof is as bad - or worse - than a method like this).
Second, a theoretical proof is sometimes more interesting for the secondary results it produces and the new avenues of progress in other areas, rather than in the proof itself. This is generally lacking for brute-force methods.
But in reality, these methods complement each other quite nicely. Knowing what the result should be, making an elegant classical proof of it becomes so much easier than before. And of course, you tend to need to know quite a lot about a problem (culled from classical methods) before you can formulate a prq'acticable brute-force approach.
I have seen this effect as well, among my friends that has gone to Linux from Windows. 6 out of 8 have ended up running Gnome over KDE, and this is one of the reasons for many of them. They typically dual-boot and/or use Windows at work, and they feel KDE to be clumsy, simply because they mix them up at the "fingertip" level and thus get the impression that things do not work well.
On the upside, this effect seems to go the other way as well; their opinion of Windows really took a dive during the first months of Linux use.
Basically, the reason is that to be effective in any desktop, people rapidly learn reflexive mappings between what they see and what to do, to achieve a certain, desired, outcome. With two desktops that are very similar (but not identical) to each other, what they see is similar enough that it triggers responses for the wrong desktop. Also, when the actions needed are very similar (but not identical) you get interference in learning the correct actions.
In the end, it seems the spartan UI of Gnome is both different enough, and easy enough to map as above, to make for a very quick transition. Apart from this, most also are fairly relieved with the sparseness; comments like "it's so clean", and "it's easy to find what I want" are common.
Don't forget that the vast majority of computer users are like the majority of car owners: it's a tool. A good tool, a tool you easily can become attached to, but a tool nonetheless. We who frequent places like slashdot are really the computing equivalent of hotrodders. Nice hobby, but you would never build a mainstream car based on their preferences.
Depends on what you mean.
Python, Perl and Ruby are all very good interpreted, flexible, rapid-prototyping languages. They all have their relative strengths and weaknesses, but all are good enough that if you are choosing between them, it boils down pretty much to your own preferences and what coworkers and other people around you use (or on what animal you prefer on the cover of your reference literature:) ).
If you mean this class of languages as opposed to C, C++, Java and so on, well, it becomes a matter of what you want to accomplish. The great benefits of these interpreted languages are that they make development very fast, compared to the more traditional languages (yes, Java is interpreted, but it is still designed as a traditional language). You spend more time solving your task and less time managing the mechanics of development. Also, they really make use of the benefits of being interpreted with things like closures, dynamic code evaluation and so on. And they typically have very complete, transparent access to the surrounding system - why spend two days writing some hairy functionality when you can trivially filter your data through an external application that already does the whole job for you? Do not underestimate "scripting type glue".
They do make a pretty good fit running large systems - the Swedish pension management system is all written in Perl, for instance, and Zope is written in Python. They are also quite efficient; they are on the whole as fast as a Java implementation, and occasionally (when the task plays to the specific language's strengths), quite a bit faster.
I typically use C/C++ and Perl for development, and every time I've been using Perl for a while, I get bouts of frustration with traditional languages for the lack of such things as hash datatypes and inline regular expressions. But for some tasks, traditional languages are the way to go.
Umm, huh? I've had this sig on slashdot for ages. Or are you thinking of the nwn boards?
An interesting twist is that is this ridiculous line of reasoning would stand, it means the BSD license is invalid too (and all that code reverts to the original copyright holder). Now, a lot of products from a lot of companies contains BSD-licensed code (MS uses BSD code in their network layer, for example). In essence, this could bring the entire IT insdustry to a screeching halt for the next five years while everybody figures out who owns what and sues each others bankrupt carcasses over it.
Should have gone to law school...
As the other poster here said, there is a six-month development cycle implemented - which really has increased speed of development.
Consider that first waiting for GTK 2.4 (a month or so), another possible month for GTK 2.4.1 (if there are any ooops:es in the 2,4 release), and another month to make sure gnome is stabilized wrt GTK. You are just a month from the next release freeze by then. And with such a long wait, you would inevitably break code freeze, or have a lot of frustrated developers on your hands.
With the current schedule, GNOME will have four months to get properly integrated with GTK 2.4, rather than hurrying it up over a month or so to get a release out the door.
Heh. I run on a hi-res laptop (1400x1050), so changing resolutions is not really a solution (tends to blur the image, as it needs to interpolate). Just upping the default text size works fine for me, though.
It's because 2.3.5 is a _development_ release. It is not intended for end-users, but for developers (which, presumably, aren't too fazed with the task). This is a preview of the 2.4 release which will happen in a few weeks.
* It does take up less, I believe (not having done any formal comparison).
* I have never seen that problem; maybe time for a bug report?
* That is Redhat, and can be turned off. Go to "Preferences" -> "CD properties".
* It won't really release all memory until you _really_ close it - as long as you want it to handle your desktop it is still running. Oh, and just like all other Linux apps, releasing memory doesn't actually release the memory as such; the pages are kept around as long as nothing else needs it, and they are still mapped to the app as long as the app is running. Looking at RSS gives you a sort-of reasonable estimate on the memory use, but it too (if I am correct) will overestimate memory use.
So long as HTML mail can be sent, it will be sent, and it will be used for spam--and for other things as well. ...and it will be dumped into my spam folder, spam or not. Sure, I look thorugh that folder a couple of times a week before emptying it, so chances are decent that a non-spam mail will be noticed and read by me. If not, tough. Same thing with mail from Hotmail, Yahoo or MSN. If it was really important, you can send it again, or call me.
Wow, it sounds great!
Now, can you just please post a link to C/C++ or Perl bindings for the toolkit? Thanks.
As I stated in another comment, that "ugly hack" type comment was entered in jest, and the story submitter chose to interpret it differently.
One reason Gnome people haven't been in any real hurry, I think, is that a lot use gkrellm, which sort of does the same thing. The Karamba people decided something better was needed and implemented their thing. Now some Gnome people find that Karamba is sweet, and does something similar in turn for Gnome (but with the great benefit of hindsight from how Karamba is used). No doubt some KDE people will learn from gDesklets and make something even better.
A developer calls it "an ugly hack". Well, not quite. It was pretty clearly marked as tongue-in-cheek, and not to be taken seriously.
Looks to me like the submitter deliberately wants to fan any remaining flames between the projects; who knows why.
Instead, we have some pretty good illustrations as to why having two projects is a really good idea. KDE gets Karamba (and SuperKaramba) which takes off like wildfire. Undaunted, some Gnome people sit down and look at what Karamba does and learns from it (what the devels envisioned versus how it is actually being used; awkwardness and mistakes in teh design) and develop something similar, but with the benefir of hindsight from the other project. No doubt will the Karamba people look at gDesklets and in turn learn from it's strengths and weaknesses. THe end result is a set of tools that become far better, faster, than either would have become on its own.
Sure - if it's as simple as finding info about Euclid's algorithm.
:/
If I want to find all texts about LTP in the amygdala, however, flipping through a dozen books and a few hundred papers just isn't the same as a quick "grep". If I want to find the source of a half-remembered quotation, I'd have to spend days to find where I read it - or spend half my reading time filling in index cards and keeping them sorted, which is what people had to do before their texts were searchable. If you want to do that, you are welcome to.
Laptop: I do have the books in paper format as well. And the size of the laptop compared to books is a non-issue; it's not laptops OR books, it's laptop, or laptop AND books.
Oh, and for all the convenience of generating vaiorus formats, you _still_ occasionally bump into PDF:s that are simply scanned pages, or where you can't extract the text for some other reason.
BTW, the title turned out wrong - Phoenix autocompleted it without me noticing it...
I download quite a lot of books. Now, most (if not all) are books I already own; this goes for fiction as well as non-fiction. I have also considered getting a scanner and OCR software to scan all those books I don't already have in machine-readable form (no good OCR scanning software for Linux as far as I've been able to tell, though). I also have several directories filled with papers downloaded from databases or from the authors' homepages.
So, if I already own the books, and books are nicer to read on paper (and they are), why have them? Convenience. Say you are going on a two-week trip. You could bring one, maybe two, books with you before it gets cumbersome. If I have my laptop with me, on the other hand, I have more or less my entire library available. This is great, both for having reference litterature with me, and for whiling away a few hours with a novel in some hotel.
The benefit is not only when traveling either. WHerever and whenever I have my computer, my books travel along. And they are searchable - this is absolutely invaluable.
A small note to other researchers: if you are putting up your papers for download, would you _please_ not just have them as PDF:s of scanned images of the pages in the paper?! They become utterly opaque to searching and indexing, and when I search through my collection for relevant stuff, I will miss your paper and you will miss a citation.
But why?
I mean, if you have a nautilus window open on an ordinary directory; or of you have a shell open in that directory, the system will silently allow you to delete the directory and it's contents without complaining about other processes still accessing it. I don't see why this should be treated differently from an UI point of view?
But a basic problem is that you aren't reminded _what_ resource is holding the disk and why.
You just get a terse message that something is using it. It could be you're burning a CD, sure, but it could also just be that you've forgotten that you have a shell open in the directory somewhere, in a non-visible tab in a terminal - possibly hiding behind an application window - on one of your workspaces.
Yes, if something is queuing for reading or writing the device, I agree, unmounting it should be prevented. If all there is is an open file descriptor (which it is 99% of the time), then it should probably protest, but allow me to just unmount the media if I insist, without me having to hunt through the system in search for whatever I (or a process I started) have left behind.
I recently bought this, and for much the same reasons as the reviewer.
Basically, if your introduction to Perl was via "Learning Perl" then this is probably a great next step. I went through the Camel book and the Perl cookbook instead, and find that this one does not give all that much more information as I would have liked. This is not strange; the authors explicitly say in the preface that this is the companion book to "Learning Perl".
On the upside, it does give a good deal of useful snippets of info, and it manages to give clear explanations for some stuff that is otherwise quite opaque; the way it explains the Perl object model, for example is much clearer to me than the treatment given in the Camel book.
I would have given it 7.5-8 rather than the extreme score the reviewer gave.
There is something called "due diligence". They are an operating systems company. They pinned a large part of their business on their Linux distribution, and did so for a couple of years. They even continued offering their distribution under GPL for a couple of months after they started trying to assert that their IP was in the kernel.
There can be a case for saying that given their area of expertise, and the importance of this component to their operations, they could reasonably be expected to know what they were selling.