Yes, a crash in a monolithic kernel will bring the whole system down. And how many people cares? Almost nobody.
Really? Remind me not to use any kernel you've been writing;-)
Seriously—it is a lot more important than you are suggesting. You are right that one must look at the computer as a whole system, rather than focussing on any particular part, but it is also important to look at the impact of failure of any one component. Yes, if a single library within openoffice does have a bug, that can take down the whole openoffice program—but that means that one user loses (probably) one or two documents from one of their running applications. If the kernel goes down, then all users on the system lose all documents from all applications they were running—and in a system where there may be tens or even hundreds of users, that's bad news!
What's more, if openoffice crashes or locks up, I can restart it myself. If an entire server locks up, I can't always fix it myself; I may have to wait for an admin to restart it.
That's all true for crashes, but it's also true for data corruption: a bug in an openoffice library may corrupt my document, but a kernel bug may end up corrupting everyone's data.
If microkernels can improve the kernel reliability so that this sort of thing happens much less often (and I'm not arguing that they can—though I think ast would!) then I'm all for them...
Yeah, that incentive is going to go over real well at a non-profit organization... Better than you might think: most NPOs that I've dealt with live on a delicate balance between survival and bankruptcy—increased efficiency then translates to improved job security for employees.
Someone got out of the wrong side of bed today;-) The flip-side to these views is as follows:
Something that is easy to replace is less valuable than something that is hard to replace. Somone who is impossible to replace is impossible to promote
Improving the process = making it more efficient = making it require less manpower = layoffs. Improving the process = making it more efficient = making it require less manpower = increased capacity = PROFIT!!!
We will go with HD when we have full access via component or dual-dvi ports, hdmi be damned.
You need to be careful: HDMI is just a connector—roughly speaking, HDMI = DVI + SPDIF (in a single, smaller, connector). HDCP (the copy-prevention protocol) runs just as happily over DVI as over HDMI, as the two are electrically identical.
On the positive side, of course, that means you don't need to rule out all products that come with HDMI ports, as it's quite possible for a device to use HDMI without being "evil".
For everyone who uses Doctype, it can be assumed that they're using some kind of html generator, Why would you assume that? It's quite common to put the DOCTYPE tag in manually (and indiscriminately) - indeed, isn't that the root of the whole problem?
I also spent countless hours making ASCII art on a OS/360 terminal (I think it was OS/360, not sure). If it was OS/360, it was probably a rare instance of "EBCDIC art" rather than ASCII;-)
The FAQ might as well be written about sunshine and lolypops because anything the FAQ says is irrelevant. No, it isn't. For one thing, it shows how the FSF/SFLC interpret the licence—and they're the ones who will sue you if they think you're distributing software they own in an infringing way. What's more, if they have made public statements (such as the FAQ) describing the way they intend their legal documents to be interpreted, a court will very likely hold them to that. So it is relevant, but I agree it's not a substitute for reading and understanding the licence.
You do know that ionizing radiation (e.g. alpha particles, beta particles, gamma rays from nuclear decay) has absolutely nothing to do with non-ionizing (e.g. radio, microwave, etc) EM radiation.
Gamma rays are a form of EM radiation... so they are related (though given that they have a much higher energy I agree that it's not that helpful to compare them in this instance).
Every time there is a leap second Linux time deviates further from UTC. No, Linux/Unix time stays roughly in step with UTC. Though Unix time only counts 86400 seconds each day, regardless of leap seconds, depending on the implementation it will either stretch the seconds for a period, or uses some time values twice, to stay close to UTC.
Seriously though, I was listing things that are problems with common languages using manual freeing, so I'll go through yours from a similar point of view:
6. Yes, this is another good point, and (some) GC schemes solve this by moving objects around during GC—so another win for using GC. 7. This is true, but it's more a difficulty in using GC in non-GC languages than a problem with manual freeing:). 8. Arguably this is a win for C++ with RAII: the 'finalise' methods provided by GC languages are often not deterministic enough to be useful (for example, using 'finalise' to close a file means you don't know when the file will get closed, so it might not have been closed by the time you need to open it again... 9. As with any discussion, real-time brings its own set of problems:-)
just use valgrind, and you can stomp out these problems quickly.
That's true, but only on a good day:-). On a bad day your uninitialised pointer will happen to point to valid, allocated memory (Valgrind won't detect that) and you'll overwrite something you shouldn't. On another bad day, the second free() of a block, or an access to its contents, will happen after Valgrind has decided to give it to someone else (it only hangs on to freed blocks for a limited time). Or your program uses mutexes in shared memory, so Valgrind doesn't handle it well. Or on a really bad day, the problem will only exhibit itself on platforms other than x86, where Valgrind won't help at all:-(.
Valgrind is a truly awesome tool, but it's not perfect by any means, and you can still end up spending lots of time debugging obscure problems (I know I have...).
If the memory is unused (no longer referenced) it will be freed. Please read carefully—you asked me to give a definition of a memory leak, and I specified memory that is no longer needed. I didn't say no longer referenced. The problem is, code can keep a reference to memory even when it doesn't need it (which would, of course, be a bug). It's a memory leak, just like one from not freeing a malloc()-ed pointer in C. It just looks different in the code:-).
Then do please tell me how you define a memory leak.
Simple, memory that has been allocated, is no longer needed, but will never be freed.
Unless you have a different definition there are no memory leaks in Java, or C# for that matter.
Obviously the objects mentioned were still referenced. Its a simple bug in their code, not a memory leak.
That's just silly. A memory leak is a simple bug in the code—saying that "all unused memory will definitely always be freed (oh, provided there are no bugs in the code)" is true whether you have a garbage collector or not:-)
In reality you have to identify/control the lifespan of objects anyway, so I personally never understood what the big deal is about freeing memory manually. Not to mention that memory leaks in say, C++ code, really aren't that hard to find. The tools have become pretty freakin decent.
I agree with you that GC has been presented as a cure for all memory leaks, and that a lot of not-very-clueful people think that you can get away with being sloppy; however I do thing that GC is a good thing: there are several problems directly related to manual allocation and freeing of memory, including:
Forgetting to initialise a pointer (access to random memory)
Attempting to access via a null reference (null pointer)
Forgetting to free memory (memory leak)
Freeing already freed memory (double free)
Accessing already freed memory (memory scribble)
Of those problems, the first can be solved without GC (by forcing/checking for initialisation), and the second at least results in a clean runtime exception.
Of the others, the double-free and memory-scribble are notoriously hard to debug, since they typically result in unpredictable behaviour that may be completely unrelated to the original problem—but GC eliminates these entirely (or at worst transforms them to memory leaks).
Ironically, given all the rhetoric, the one problem that GC doesn't eliminate (other than in relatively simple cases) is the memory leak:-). But then—as you say, it's plenty possible to provide good tools to detect and debug that sort of problem.
I just checked, and C# apparently uses reference-count garbage collection. That means that an object will stay around until there are zero references to it.
No, it does use a mark-sweep garbage collector. This does present challenges to real-time applications; I imagine the GC is tunable to some extent (I know the Java one is)...
In Europe, none of what's described in the article would be happening because you have no right to contest a ticket over there (except maybe in England since their legal system and ours have a common basis, but maybe not even there).
In the UK you can most definitely contest a speeding ticket. In fact you can in France and Spain too. What makes you think the legal systems in Europe are so unjust?
(Note that the Spanish link mentions fees of €930. You don't have to pay that to contest a ticket, that's just what some lawyer wants to charge for assisting you... seems lawyers are the same the world over;-)
Just to check: do you have the latest firmware installed on it? The Nokia N770 support page lists "Improved quality of WLAN connections" as the change made in the latest version...
Where's the -1:Wrong moderation when you need it? To be fair, the LinuxDevices page linked above does state that it still has two SD/MMC slots—so the GP's problem is not that he didn't RTFA, more that he believed it:). But you're right, according to Nokia's specifications page, it will have one miniSDHC slot, which is a pity.
Don't mention civil activism as an alternative. Even if you manage to convince a 100 voters to switch sides (which is unlikely, even if you devote large amounts of time into it), the math is the same for any reasonable population size.
Your strategy is wrong! As all MLM-ers and chain email senders know, you need to use the power of exponential growth. Why waste time convincing 100 voters? Just convince 10, and tell them to do the same, and you'll already have over 100 voters on your side. Another iteration will give >1,000, then 10,000—and before you know it you'll have 1,000,000,000 voters all on your side! More voters than there are in the entire US population! How can you possibly lose?!
Seriously though: grassroots campaigns can and do have an effect. Not nearly often enough, and it's an awful lot of work, but with an effective lobbying/campaigning organisation it is possible to influence enough people to swing a result.
I personally don't like the idea that individuals who enjoy waiting in line to drop a slip of paper into a box have a monopoly on collective decision making. But the only alternative seems to be mandatory voting.
Or postal ballots. Or having enough resources so that long lines don't ever form. Or paying people to vote. (Not that I'm actually advocating any of these—just don't let your lack of imagination leave you with the conclusion that compulsory voting is the only solution to the problem you describe:-)
Slashdot Mirror
Really? Remind me not to use any kernel you've been writing ;-)
Seriously—it is a lot more important than you are suggesting. You are right that one must look at the computer as a whole system, rather than focussing on any particular part, but it is also important to look at the impact of failure of any one component. Yes, if a single library within openoffice does have a bug, that can take down the whole openoffice program—but that means that one user loses (probably) one or two documents from one of their running applications. If the kernel goes down, then all users on the system lose all documents from all applications they were running—and in a system where there may be tens or even hundreds of users, that's bad news!
What's more, if openoffice crashes or locks up, I can restart it myself. If an entire server locks up, I can't always fix it myself; I may have to wait for an admin to restart it.
That's all true for crashes, but it's also true for data corruption: a bug in an openoffice library may corrupt my document, but a kernel bug may end up corrupting everyone's data.
If microkernels can improve the kernel reliability so that this sort of thing happens much less often (and I'm not arguing that they can—though I think ast would!) then I'm all for them...
dabris? Don't you mean dabis? (And I've a feeling it should be immanem but it's a long time since I studied these things...)
You need to be careful: HDMI is just a connector—roughly speaking, HDMI = DVI + SPDIF (in a single, smaller, connector). HDCP (the copy-prevention protocol) runs just as happily over DVI as over HDMI, as the two are electrically identical.
On the positive side, of course, that means you don't need to rule out all products that come with HDMI ports, as it's quite possible for a device to use HDMI without being "evil".
Gamma rays are a form of EM radiation... so they are related (though given that they have a much higher energy I agree that it's not that helpful to compare them in this instance).
Isn't that what they used to call "talking"? ;-)
s/Defoe/Swift/
What about them? ;-)
Seriously though, I was listing things that are problems with common languages using manual freeing, so I'll go through yours from a similar point of view:
6. Yes, this is another good point, and (some) GC schemes solve this by moving objects around during GC—so another win for using GC. :). :-)
7. This is true, but it's more a difficulty in using GC in non-GC languages than a problem with manual freeing
8. Arguably this is a win for C++ with RAII: the 'finalise' methods provided by GC languages are often not deterministic enough to be useful (for example, using 'finalise' to close a file means you don't know when the file will get closed, so it might not have been closed by the time you need to open it again...
9. As with any discussion, real-time brings its own set of problems
That's true, but only on a good day :-). On a bad day your uninitialised pointer will happen to point to valid, allocated memory (Valgrind won't detect that) and you'll overwrite something you shouldn't. On another bad day, the second free() of a block, or an access to its contents, will happen after Valgrind has decided to give it to someone else (it only hangs on to freed blocks for a limited time). Or your program uses mutexes in shared memory, so Valgrind doesn't handle it well. Or on a really bad day, the problem will only exhibit itself on platforms other than x86, where Valgrind won't help at all :-(.
Valgrind is a truly awesome tool, but it's not perfect by any means, and you can still end up spending lots of time debugging obscure problems (I know I have...).
Simple, memory that has been allocated, is no longer needed, but will never be freed.
Unless you have a different definition there are no memory leaks in Java, or C# for that matter. Obviously the objects mentioned were still referenced. Its a simple bug in their code, not a memory leak.That's just silly. A memory leak is a simple bug in the code—saying that "all unused memory will definitely always be freed (oh, provided there are no bugs in the code)" is true whether you have a garbage collector or not :-)
I agree with you that GC has been presented as a cure for all memory leaks, and that a lot of not-very-clueful people think that you can get away with being sloppy; however I do thing that GC is a good thing: there are several problems directly related to manual allocation and freeing of memory, including:
Of those problems, the first can be solved without GC (by forcing/checking for initialisation), and the second at least results in a clean runtime exception.
Of the others, the double-free and memory-scribble are notoriously hard to debug, since they typically result in unpredictable behaviour that may be completely unrelated to the original problem—but GC eliminates these entirely (or at worst transforms them to memory leaks).
Ironically, given all the rhetoric, the one problem that GC doesn't eliminate (other than in relatively simple cases) is the memory leak :-). But then—as you say, it's plenty possible to provide good tools to detect and debug that sort of problem.
No, it does use a mark-sweep garbage collector. This does present challenges to real-time applications; I imagine the GC is tunable to some extent (I know the Java one is)...
Don't you mean 'caveat lector', unless it's intended to be a subtle sales pitch for your employer? ;-)
In the UK you can most definitely contest a speeding ticket. In fact you can in France and Spain too. What makes you think the legal systems in Europe are so unjust?
(Note that the Spanish link mentions fees of €930. You don't have to pay that to contest a ticket, that's just what some lawyer wants to charge for assisting you... seems lawyers are the same the world over ;-)
Just to check: do you have the latest firmware installed on it? The Nokia N770 support page lists "Improved quality of WLAN connections" as the change made in the latest version...
Congratulations—I think that's the worst joke I've ever seen on slashdot. That's quite an achievement :-p
Your strategy is wrong! As all MLM-ers and chain email senders know, you need to use the power of exponential growth. Why waste time convincing 100 voters? Just convince 10, and tell them to do the same, and you'll already have over 100 voters on your side. Another iteration will give >1,000, then 10,000—and before you know it you'll have 1,000,000,000 voters all on your side! More voters than there are in the entire US population! How can you possibly lose?!
Seriously though: grassroots campaigns can and do have an effect. Not nearly often enough, and it's an awful lot of work, but with an effective lobbying/campaigning organisation it is possible to influence enough people to swing a result.
I personally don't like the idea that individuals who enjoy waiting in line to drop a slip of paper into a box have a monopoly on collective decision making. But the only alternative seems to be mandatory voting.Or postal ballots. Or having enough resources so that long lines don't ever form. Or paying people to vote. (Not that I'm actually advocating any of these—just don't let your lack of imagination leave you with the conclusion that compulsory voting is the only solution to the problem you describe :-)