Indeed, I was wrong. There are some constraints on CIL generation that might make optimization easier, but that's it. JVM and CIL bytecode contain the same amount of explicit information.
I wish I had the option of retracting the original post, now. Hopefully someone will at least mod you up.
2's the big thing. Why should we use something when Microsoft controls the implementation, anyway? That's just standing still on the carpet waiting to get it yanked out from under you.
CLR is actually a nice technology, but it seems to me using open-source implentations of it are the only way to go if you're going to use it. They did at least submit the important material to ECMA.
It also means the possibility for a form of binary compatibility with e.g. Unix systems that didn't exist before. An Open Source Unix implementation would be pretty nice to have -- which happens to be what Mono is doing.
It looks to me like enough of the core libraries are part of the ECMA standard that, once implemented, they'd provide almost the same level of compatibility (except binary, not just source) between the Mono CLR on Linux/Unix and the Microsoft CLR on Windows as there is between GNUStep and MacOS X.
That's icing, though. Microsoft could always play their usual compatibility games, limiting the usefulness of CLR for that purpose. Whether or not it's 100% compatible with Microsoft's version, if you have your own implementation that Microsoft doesn't control it's a really useful technology just for the sake of e.g. cross-platform Linux development.
There are some annoying things in CLR, but overall it's an improvement over the JVM (as practiced).
Note I'm not addressing C# versus Java as languages. You can host many different languages on both the JVM and CLR, although Microsoft seems to be actively touting that fact more than Sun is right now.
Normally CLI is compiled to native machine code rather than interpreted. CLI bytecode also carries a lot more useful information for optimization than JVM bytecode does (as well as placing some restrictions on code generation that make it easier than JVM to compile efficiently).
There are similarities to (for example) the "Limbo of the Fathers" (which is probably what you're thinking of in Dante's work). I'm not sure if mythology is the right word or not. At any rate it is fairly widely held in some Catholic circles, but it's not defined as a Catholic doctrine per se.
[ I should note that Dante's Inferno, though extremely culturally influential, isn't really very doctrinally accurate in general; as I understand it he wrote it shortly after his conversion, and there is the very heavy influence of e.g. Etruscan myths of the afterlife. I don't think he originated the idea of Limbo, however. ]
It would be interesting to know what Tolkien's own beliefs were in that area and how/if they relate to his treatment of the elves in LotR -- he was, after all, Catholic. However, from what I've seen, it seems like he thought of the elves more as sort of what man would have been like had he not fallen.
They'd still have to learn the semantics of the tags. XML _only_ provides a common syntax/metasyntax, and not even that pleasant a one (although it does have a lot of nice features).
If the worst-case scenario is no worse than not using the service at all, then it still sounds like a good deal to me.
Of course, there is probably a "worse-case" scenario: the site that maintains the list is hacked, and everyone downloads lists that match and subsequently block ALL traffic, legitimate and otherwise....or possibly just the same thing happening as a result of incompetence.
RedHat ships an -ac kernel with RH 7.2, I think 7.1's was also an -ac kernel.
Not pure -ac kernel, though, like most major distributions they also pull stuff from Linus and other kernel trees (there are others) so what they actually ship is really the "RedHat" tree.
The party in question would have to subsidize their own bandwidth costs somehow. Mirroring slashdot -- especially if people are actually visiting your mirror -- is not exactly cheap.
Certainly for micropayments anyway. If you have a professional/business account (necessary to implement e.g. a "pay me" link on your page or other arrangement) they skim a minimum of $.30 US plus some (small) percentage from every transaction.
Obviously, that doesn't make sense for very small payments (~$.10 US), let alone micropayments (~$.0002 US).
Dynamic allocation isn't necessarily safe in all the places printk() can be (is) used.
There are some points in the kernel at which you just cannot touch the parts of the VM subsystem that would be necessary to dynamically allocate memory. It's not a design flaw; it's just a constraint of the way locking and reentrancy have to be handled.
With a lot of work, you could probably create a dynamically allocating printk(), but you'd have to introduce a tremendous amount of additional locking just to support printk(), which would kill performance, and would mean that printk() couldn't be used in many places that it is now (certain interrupt handlers where the locking overhead would be too much).
Also, an obvious one... what happens if the printk() happens to be reporting something due to VM exhaustion?....from within the VM subsystem?
The static printk() buffer is a necessary design decision.
Process creation under Linux (>= 2) is cheaper than on many other systems, however. It's (usually) still a net win.
OTOH, for _kernel level_ threads, you need more than just a register context and stack -- the scheduler ends up needing a fair amount of bookkeeping data anyway.
Linus just decided that there's not much point in making threads a special case ("thread-like" behavior depends on which of several things are shared, specified by flags).
Things get a lot simpler that way, and is probably one reason why thread and process creation are so cheap on Linux.
Even the recently added CLONE_THREAD stuff is a pretty generalist approach -- it just controls whether or not threads (including those considered "processes") share a "thread group" (the id reported by getppid(2) in 2.4).
Transcoding from one lossy codec to another is not really a useful way to compare them.
Loss due to lossy compression is cumulative.
You lost some sound quality in the original CD -> MP3 encoding, and then lost some more in the MP3 -> VQF encoding (or MP3 -> WAV -> VQF, same thing).
To sound halfway decent, VQF may well want information that was thrown out in the original MP3 encoding pass.
The only fair comparison would be between CD -> MP3 and CD -> VQF.
[ not that I really have any great desire to defend VQF in general... it wasn't THAT good and deserved to die for other reasons, but it's certainly better than you experienced ]
Slashdot Mirror
Indeed, I was wrong. There are some constraints on CIL generation that might make optimization easier, but that's it. JVM and CIL bytecode contain the same amount of explicit information.
I wish I had the option of retracting the original post, now. Hopefully someone will at least mod you up.
... as far as that goes, I agree with you. What's the "Not really." in response to?
I feel dumb. I've been typing CLI everywhere when I meant CIL. >
2's the big thing. Why should we use something when Microsoft controls the implementation, anyway? That's just standing still on the carpet waiting to get it yanked out from under you.
CLR is actually a nice technology, but it seems to me using open-source implentations of it are the only way to go if you're going to use it. They did at least submit the important material to ECMA.
It also means the possibility for a form of binary compatibility with e.g. Unix systems that didn't exist before. An Open Source Unix implementation would be pretty nice to have -- which happens to be what Mono is doing.
It looks to me like enough of the core libraries are part of the ECMA standard that, once implemented, they'd provide almost the same level of compatibility (except binary, not just source) between the Mono CLR on Linux/Unix and the Microsoft CLR on Windows as there is between GNUStep and MacOS X.
That's icing, though. Microsoft could always play their usual compatibility games, limiting the usefulness of CLR for that purpose. Whether or not it's 100% compatible with Microsoft's version, if you have your own implementation that Microsoft doesn't control it's a really useful technology just for the sake of e.g. cross-platform Linux development.
There are some annoying things in CLR, but overall it's an improvement over the JVM (as practiced).
Note I'm not addressing C# versus Java as languages. You can host many different languages on both the JVM and CLR, although Microsoft seems to be actively touting that fact more than Sun is right now.
Normally CLI is compiled to native machine code rather than interpreted. CLI bytecode also carries a lot more useful information for optimization than JVM bytecode does (as well as placing some restrictions on code generation that make it easier than JVM to compile efficiently).
There are similarities to (for example) the "Limbo of the Fathers" (which is probably what you're thinking of in Dante's work). I'm not sure if mythology is the right word or not. At any rate it is fairly widely held in some Catholic circles, but it's not defined as a Catholic doctrine per se.
[ I should note that Dante's Inferno, though extremely culturally influential, isn't really very doctrinally accurate in general; as I understand it he wrote it shortly after his conversion, and there is the very heavy influence of e.g. Etruscan myths of the afterlife. I don't think he originated the idea of Limbo, however. ]
It would be interesting to know what Tolkien's own beliefs were in that area and how/if they relate to his treatment of the elves in LotR -- he was, after all, Catholic. However, from what I've seen, it seems like he thought of the elves more as sort of what man would have been like had he not fallen.
XPCOM is a different beast from Microsoft's COM.
CORBA is more comparable to DCOM, btw.
They'd still have to learn the semantics of the tags. XML _only_ provides a common syntax/metasyntax, and not even that pleasant a one (although it does have a lot of nice features).
i++;
If the worst-case scenario is no worse than not using the service at all, then it still sounds like a good deal to me. Of course, there is probably a "worse-case" scenario: the site that maintains the list is hacked, and everyone downloads lists that match and subsequently block ALL traffic, legitimate and otherwise. ...or possibly just the same thing happening as a result of incompetence.
Actually it's a de jure monopoly now.
RedHat ships an -ac kernel with RH 7.2, I think 7.1's was also an -ac kernel.
Not pure -ac kernel, though, like most major distributions they also pull stuff from Linus and other kernel trees (there are others) so what they actually ship is really the "RedHat" tree.
The party in question would have to subsidize their own bandwidth costs somehow. Mirroring slashdot -- especially if people are actually visiting your mirror -- is not exactly cheap.
He didn't, he didn't, and you won't.
Thank God.
Certainly for micropayments anyway. If you have a professional/business account (necessary to implement e.g. a "pay me" link on your page or other arrangement) they skim a minimum of $.30 US plus some (small) percentage from every transaction. Obviously, that doesn't make sense for very small payments (~$.10 US), let alone micropayments (~$.0002 US).
It's more of the same sort of US-directed xenocentrism that spawns stuff like Engrish.
It's kind of sad (I happen to LIKE having other cultures around, dammit :/), but I suppose it at least has some entertainment value.
I'm sorry, the idea just gives me the creeps.
Dynamic allocation isn't necessarily safe in all the places printk() can be (is) used.
... what happens if the printk() happens to be reporting something due to VM exhaustion? ....from within the VM subsystem?
There are some points in the kernel at which you just cannot touch the parts of the VM subsystem that would be necessary to dynamically allocate memory. It's not a design flaw; it's just a constraint of the way locking and reentrancy have to be handled.
With a lot of work, you could probably create a dynamically allocating printk(), but you'd have to introduce a tremendous amount of additional locking just to support printk(), which would kill performance, and would mean that printk() couldn't be used in many places that it is now (certain interrupt handlers where the locking overhead would be too much).
Also, an obvious one
The static printk() buffer is a necessary design decision.
Process creation under Linux (>= 2) is cheaper than on many other systems, however. It's (usually) still a net win.
OTOH, for _kernel level_ threads, you need more than just a register context and stack -- the scheduler ends up needing a fair amount of bookkeeping data anyway.
Linus just decided that there's not much point in making threads a special case ("thread-like" behavior depends on which of several things are shared, specified by flags).
Things get a lot simpler that way, and is probably one reason why thread and process creation are so cheap on Linux.
Even the recently added CLONE_THREAD stuff is a pretty generalist approach -- it just controls whether or not threads (including those considered "processes") share a "thread group" (the id reported by getppid(2) in 2.4).
64-bit *nix varients have used a 64-bit time_t since time immemorial. The 32->64 bit migration was anticipated.
FWIW, 64 bits puts the new rollover date well past the probable heat death of the universe.
"How many Slashdotters does it take to change a light bulb?"
62% say "CowboyNeal".
The thin metallic layer in CDs will oxidize after about 50 years...
Dude, even WinAmp ships with a Vorbis plugin these days.
Transcoding from one lossy codec to another is not really a useful way to compare them.
... it wasn't THAT good and deserved to die for other reasons, but it's certainly better than you experienced ]
Loss due to lossy compression is cumulative.
You lost some sound quality in the original CD -> MP3 encoding, and then lost some more in the MP3 -> VQF encoding (or MP3 -> WAV -> VQF, same thing).
To sound halfway decent, VQF may well want information that was thrown out in the original MP3 encoding pass.
The only fair comparison would be between CD -> MP3 and CD -> VQF.
[ not that I really have any great desire to defend VQF in general