...I think she should have split the final book into two books (but the same timeframe, so it would be Deathly Hallows Pts 1 and 2), giving herself the space needed to finish the story without overly compressing anything. It is always a serious error when an author works to a maximum number of pages and then realizes they can't possibly put everything that needs to be there in. You're going to end up with shortcuts.
(Tolkien made that error with LoTR. There are six "books" there, but the final one is horribly rushed in comparison to the others. If Book six had expanded out into books 7 and maybe 8, he could have cleaned up a lot of things. Yes, he had enough trouble getting a publisher as it was. The tape recordings were made during the time of deepest despair. Ultimately, though, a few more chapters probably wouldn't have made it any harder of a sell and would have added texture and flavor that ended up missing.)
You are correct. Unfortunately, epics don't translate well to the big screen - one reason Tolkien never wanted his work to be turned into a movie. Now, it may be possible to do, but it requires the story to be expanded, not compressed. This is the exact opposite of how Hollywood thinks. Hollywood thinks in terms of individual blockbusters, not serialized productions, but serialization is the ONLY way you can hope to capture the feel of a book of the size of Order of the Phoenix.
Yes, it would be horribly expensive. Yes, you are unlikely to get nearly as many people prepared to watch through the whole thing. Yes, the logistics would be a nightmare. But if you want to capture the feel of the world drama of which Harry Potter is an important part but only a part, you need to be looking at a much slower pace with a lot more detail. An hour a chapter (on average) would probably be about right.
In television terms, the first two books would probably be about a season's worth of hour-long episodes. The third book would take an entire season on its own. Of the remainder, they might even require a double-length or triple-length season each. Now, Star Trek: DS9 3/4 certainly had stories spanning multiple episodes, but that's generally not how stories are done these days.
Even the BBC, whose serializations of "Pride and Prejudice", "The Day of the Triffids" and "Edge of Darkness" had people on the edge of their seats for long stretches of time, has cut back on such work, and whilst they pulled 40-odd episode seasons with Doctor Who in the 1960s, I can't seriously believe they'd even consider putting child actors (or any other actors) through that kind of stress in this day and age. Nor can I believe that anybody but the most die-hard of fan would even watch such a production.
That's the horticrux of the problem. Either the production would be done right, or be watchable by a modern audience. I don't think you're going to be able to do both.
Infiniband has an end-to-end latency of 8us and can scale to 160 Gb/s. Dolphinics SCI has an end-to-end latency of 2.8us. Picture a SAN that beats the crap out of most local storage. Now picture driving this monster through a 21us latency context switch and a data copy between kernel to userspace. It's not a pretty thought.
But what happens if you do this right? Sure, most single drives can't handle that kind of throughput right now, but scalability and future-proofing are important. There's no point in having a mechanism which is OK for today but useless three weeks from now.
There's a 21us hit every time you context-switch, which would hurt on very high-performance drives but is probably below the threshold of being obvious for network-based storage and really slow drives. However, a few intelligent drives supposedly support total kernel bypass and zero-copy - basically the drive remote DMAs the data into and out of memory, once told where things are. This would only require kernel access for initializing the transfer and locking down the pages. I seriously doubt, though, that any of these will be common uses for the userspace drivers.
The most common use, I would imagine, would be as a testbed platform. Writing things directly into the kernel has many unquantifiable variables - I'm highly respectful of all who develop kernel code on a regular basis, that is no small achievement. Developing the same code in userspace with an API to link over eliminates many of the possible ways you can screw up a machine, although the code would still need to be written with an eye to being used in kernel space. For much of the writing and testing, though, you'd be in a more predictable environment.
The second-most common use would be for proprietary closed-source drivers to be written for userspace. Writing them for the kernel is problematic as the kernel internals change too much, and many such companies spend so little on maintenance that the drivers rapidly become obsolete - requiring users to either use inferior kernels or different technology, with the latter often not being possible or practical. I don't imagine older Linux drivers to be ported this way, any more than they've been maintained by the pathetic commercial vendors who pull such stunts, but newer such drivers should now be less pathetic and marginally more portable, which will be good.
Oh, wrt comments by others, Linux should absolutely never become a microkernel. Message-passing as a methodology is barely adequate for networks - RPC and CORBA are hardly famed for their elegance or performance, and when was the last time you saw Globus or MPI being used to link machines in a LAN gaming session? For that matter, STREAMS has been available for Linux since about Linux 1.2, if I recall correctly. I can't think of a single driver - even outside any of the standard or experimental trees - that uses it. I like the idea of such a patch, as I like the idea of maximum flexibility, but if it were truly useful, it would be used. It isn't.
That would need to be the game. The Red Rover gate in The Three Investigators looks nothing like the robots.... well, depending on how close that storm gets, I suppose they might...
Microsoft has just allocated one billion US dollars on fixing problems with the XBox -- and still posted a sizable profit. So, one must ask: (a) how likely is it that they wouldn't pay a few hundred extra dollars for extra disk drives, and (b) how likely is it that they'd give a damn if anyone sued them anyway?
My guess is that Microsoft will have bought the drives in bulk (it's cheaper and easier) and are very unlikely to be coming even remotely close to being in a position where Hotmail couldn't be allocated an extra gig or ten for every user on the system. That's not to say the space actually has been made available, or that it'd be efficiently used if they did, only that I cannot imagine Microsoft not being in a position to do whatever they wanted. They're stupid and naive in many ways, but under-resourced they are not.
My other guess is that if they can afford to lose a billion dollars a quarter and still post a profit, I do not believe there are sufficient users on the Internet (never mind on Hotmail) to give them any significant cause for concern, so even if a lawsuit was attempted and succeeded (most unlikely), the most significance it'd have for them is that their turnover rate of chairs would go up. I'm surprised the EU court case is giving them so much grief. If a billion dollars is chump change, can't they just buy the EU and turn it into part of their corporate empire?
OpenMosix was also fork-and-forget at the PID level. There was an effort to make it fork-and-forget at the level of individual threads, but nobody could figure out how to solve the latency hell that is synchronized shared memory. I believe that it may be partially solvable by using reliable multicasts - only one transmit per update, not one transmit per node - and by using kernel bypass tricks to avoid the 20ms context switch for large updates.
OpenSSI was part of one-stop solutions, if I remember correctly, the doomed Compaq foray into clustering before HP took them over. Doomed? Well, HP has not exactly been Linux-friendly. Their efforts to be more so by hiring Bruce Perens never panned out and you certainly don't see them porting any of their HPUX security to Linux.
I wouldn't have thought so - the gradient is non-uniform and there's a point of inflection. Ergo, the resultant force at any two points along the shape must be different. Since energy is force times time, the energy can't possibly be uniformly distributed. This would be true however the shape was created, provided there was some interaction between any given point and neighboring points.
Oh, you're absolutely right, and that's precisely because you must be able to do the low-level stuff, if you're an admin. And the command line is a powerful facility. NEVER be without one. Even non-admins should be familiar with command lines, because some things need the extra control.
However, only an idiot would rely solely on the command line for everything. Why? Let's look at Linux for a moment. You're pretty much guaranteed ash-level scripting at a minimum on the system, but any shell script on the system could potentially be written in more than two dozen scripting languages. Linux networking - are you using net-tools derivatives or iputils derivatives? The syntax isn't identical. Basic commands - GNU or Heirloom? Makes a difference. So even for something as "standard" as a Linux environment, there are a gigantic number of permutations.
This is not a bad thing. Different tools for different needs. It's a very good thing. But if there's nothing to abstract the details, you'd better have a damn good memory. I'm very very good at remembering such trivia, but I would not be capable of going to absolutely any Linux box using well-established tools and be 100% guaranteed a command line environment I could use. Nobody at all is that good.
I am fine for admining most Linuxes, HPUX, Solaris, SunOS, OSF/1, FreeBSD, OpenBSD, VxWorks and about a dozen other Un*x variants and derivatives. But in a real-world environment, to be truly optimal, you SHOULD be looking at 20+ different types of Operating system. Random administration of twenty totally different environments is possible, but you WILL want the basics to be abstracted out. It could be GUI-based, it could be shell scripts. Who cares? I'm not saying the solution has to be graphical, only that it has to be abstract. (By graphical, I'm including ncurses, as you can webmin with links or lynx perfectly well, and linuxconf is still a perfectly viable abstraction layer, albeit just for the one OS.)
The days of single-OS environments (especially "Windows shops") are numbered. It's not a viable model any more. You really can't use a hammer for everything and expect to get the results of a well-equipt craftsman or artisan. The model of the artisan is the model that the IT industry desperately needs to get back to. We are masters of our crafts, we should be respected as such, and we should be at the forefront of eliminating single solutions. Single solutions are BAD. They eliminate your ability to adapt, they restrict your thinking and they make you vulnerable to any flaws or limitations they may have. Since the first days of Open Source, you've never needed to be a prisoner to any method. The methods are YOUR servants, not the other way around.
Mandatory encryption won't help a whole lot. Mandatory access controls that utilize encryption might help some - it doesn't protect off-site data but DOES limit the device you copy data onto, as the device must be authorized to hold the data. It is then the problem of the device as to how to protect things. Not perfect, but a major improvement, as it means Joe "The Spy" User can't copy onto an unauthorized device to decrypt later at Evil HQ, and Fred "The Idiot" Flintstone can't copy top secret DoD construction plans onto public FTP servers. As has happened, according to reports.
(The point of MAC is that MAC requires that there be explicit permission given by someone who has the authority to give that permission. It is not implicit, unlike DAC where anything not expressly prohibited is implicitly allowed.)
The encryption thing can be improved on a little, if it is not secret key -or- uses an OTP calculator that only resides on authorized machines. The latter is getting a little into security through obscurity, but still works to a degree if the calculator is any good and the underlying crypto is sufficiently strong. As async encryption is slow, you'd probably want a crypto accelerator, but there are countless such systems. Don't blame the algorithms if you don't want the solutions.
Is it just me, or is there something that needs rethinking in the statement: "How is an approach that uses a standard Unix utility... shockingly unexceptional"? (emphasis mine) Either the phrasing was unintentional, or one person on this site is having problems understanding "exceptional".
By-the-by, most simple functions can be performed via webmin or some other admin tool, in a way that is platform-agnostic to the user. Well, when the module is written correctly, that is. A number are very poor. However, unless you are doing something that requires specific platform awareness, it should be for the tool to do things in the most effective way for a specific platform.
Administrators - ideally - should know principles, methodologies and other higher-level detail, except when low-level detail adds something of value. Which happens and there's no escaping it. When such low-level detail is needed, you WANT to know the syscalls, the user/kernel sockets, the virtual filesystems that provide direct access to kernel parameters. When you are doing high-level operations, you absolutely do NOT want to be messing at that level. You can't possibly hope to keep a heterogeneous network going if you have to micromanage each platform.
(In fact, most corp networks are very homogeneous because their admins are inept enough TO micromanage and therefore CANNOT cope with having multiple platforms. Remember, no homogeneous system - however good - will ever have the best solution to any of the problems before it. It will be a compromise on everything. Heterogeneous networks can always have optimal solutions for everything, requiring only that you use abstract thinking and abstract mechanisms for all the generic stuff.)
Occam scales to a (theoretically) infinite number of cores, but suffered from the drawback of being too hard to program in. I would not want Linux, or any other OS, to be ported to it - too many programmers are involved and it's too lard a language.
Now, let's look at some of the nastier userland stuff. Glibc is maintained by a fairly closed group, is mission-critical, and is notorious for all kinds of quirks and misbehaviours. Rewriting the C library in Occam, then, makes some sense - what we have is really not very usable, but it's vital that it be so.
X is another one, for much the same reason, however adding in that it's horrible on multithreading. It doesn't have any. See every single b**** discussion on the Linux scheduler - here or anywhere else. Replacing X makes sense, because what we have is unmaintainable at best. Alternatives, such as Berlin, were interesting but suffered from a range of problems - GUIs are not easy to write. Occam, although a pain, at least helps you to make sure the code does what you expect, reliably. Of course, Berlin opting for CORBA may not have been terribly smart - CORBA at the time was too heavy, and even now is heavier than it has any business being. Having said that, the idea of having a distributable GUI does make a lot more sense on modern architectures and modern environments. That, however, isn't the way it's going to get solved.
...dark energy has fallen into an interdimensional rift in the fabric of space/time, can we shove the astrophysicists who insist on inventing the unobservable to fix their theories in with them, and get on with fixing whatever the error in the models really is? Please?
There is nothing worse than a scientist who fixes the observation to meet their theory, to paraphrase the illustrious but equally fictional Sherlock Holmes.
Slashdot Mirror
Maybe we could take out a Government grant to research how innovative it is.
(Tolkien made that error with LoTR. There are six "books" there, but the final one is horribly rushed in comparison to the others. If Book six had expanded out into books 7 and maybe 8, he could have cleaned up a lot of things. Yes, he had enough trouble getting a publisher as it was. The tape recordings were made during the time of deepest despair. Ultimately, though, a few more chapters probably wouldn't have made it any harder of a sell and would have added texture and flavor that ended up missing.)
That's memorialized in a screenshot? Eeep! And I thought my slashdot addiction was bad. (Now, if only it was in postscript, rather than PNG...)
Yes, it would be horribly expensive. Yes, you are unlikely to get nearly as many people prepared to watch through the whole thing. Yes, the logistics would be a nightmare. But if you want to capture the feel of the world drama of which Harry Potter is an important part but only a part, you need to be looking at a much slower pace with a lot more detail. An hour a chapter (on average) would probably be about right.
In television terms, the first two books would probably be about a season's worth of hour-long episodes. The third book would take an entire season on its own. Of the remainder, they might even require a double-length or triple-length season each. Now, Star Trek: DS9 3/4 certainly had stories spanning multiple episodes, but that's generally not how stories are done these days.
Even the BBC, whose serializations of "Pride and Prejudice", "The Day of the Triffids" and "Edge of Darkness" had people on the edge of their seats for long stretches of time, has cut back on such work, and whilst they pulled 40-odd episode seasons with Doctor Who in the 1960s, I can't seriously believe they'd even consider putting child actors (or any other actors) through that kind of stress in this day and age. Nor can I believe that anybody but the most die-hard of fan would even watch such a production.
That's the horticrux of the problem. Either the production would be done right, or be watchable by a modern audience. I don't think you're going to be able to do both.
After going bad, Voldemort tries to hire the milk to kill Harry but ends up with cowpox.
But what happens if you do this right? Sure, most single drives can't handle that kind of throughput right now, but scalability and future-proofing are important. There's no point in having a mechanism which is OK for today but useless three weeks from now.
The most common use, I would imagine, would be as a testbed platform. Writing things directly into the kernel has many unquantifiable variables - I'm highly respectful of all who develop kernel code on a regular basis, that is no small achievement. Developing the same code in userspace with an API to link over eliminates many of the possible ways you can screw up a machine, although the code would still need to be written with an eye to being used in kernel space. For much of the writing and testing, though, you'd be in a more predictable environment.
The second-most common use would be for proprietary closed-source drivers to be written for userspace. Writing them for the kernel is problematic as the kernel internals change too much, and many such companies spend so little on maintenance that the drivers rapidly become obsolete - requiring users to either use inferior kernels or different technology, with the latter often not being possible or practical. I don't imagine older Linux drivers to be ported this way, any more than they've been maintained by the pathetic commercial vendors who pull such stunts, but newer such drivers should now be less pathetic and marginally more portable, which will be good.
Oh, wrt comments by others, Linux should absolutely never become a microkernel. Message-passing as a methodology is barely adequate for networks - RPC and CORBA are hardly famed for their elegance or performance, and when was the last time you saw Globus or MPI being used to link machines in a LAN gaming session? For that matter, STREAMS has been available for Linux since about Linux 1.2, if I recall correctly. I can't think of a single driver - even outside any of the standard or experimental trees - that uses it. I like the idea of such a patch, as I like the idea of maximum flexibility, but if it were truly useful, it would be used. It isn't.
That would need to be the game. The Red Rover gate in The Three Investigators looks nothing like the robots.... well, depending on how close that storm gets, I suppose they might...
For all we know they hired 10,000 janitors and have trouble finding programmers.
You mean, they got 10,000 employees to transfer from Microsoft? Now we know Google is doomed.
My guess is that Microsoft will have bought the drives in bulk (it's cheaper and easier) and are very unlikely to be coming even remotely close to being in a position where Hotmail couldn't be allocated an extra gig or ten for every user on the system. That's not to say the space actually has been made available, or that it'd be efficiently used if they did, only that I cannot imagine Microsoft not being in a position to do whatever they wanted. They're stupid and naive in many ways, but under-resourced they are not.
My other guess is that if they can afford to lose a billion dollars a quarter and still post a profit, I do not believe there are sufficient users on the Internet (never mind on Hotmail) to give them any significant cause for concern, so even if a lawsuit was attempted and succeeded (most unlikely), the most significance it'd have for them is that their turnover rate of chairs would go up. I'm surprised the EU court case is giving them so much grief. If a billion dollars is chump change, can't they just buy the EU and turn it into part of their corporate empire?
The Government spends money on everything else, why not spend it on something useful?
It's clearly a bill aimed at stopping sex on State boundaries.
What, you're really trying to set it back further?
The tracks can wobble on independent threads under BeOS.
OpenSSI was part of one-stop solutions, if I remember correctly, the doomed Compaq foray into clustering before HP took them over. Doomed? Well, HP has not exactly been Linux-friendly. Their efforts to be more so by hiring Bruce Perens never panned out and you certainly don't see them porting any of their HPUX security to Linux.
Gaah. You are correct. (My excuse is that I'd failed to update my brain to the latest Linux kernel, causing an unexpected error.)
I wouldn't have thought so - the gradient is non-uniform and there's a point of inflection. Ergo, the resultant force at any two points along the shape must be different. Since energy is force times time, the energy can't possibly be uniformly distributed. This would be true however the shape was created, provided there was some interaction between any given point and neighboring points.
However, only an idiot would rely solely on the command line for everything. Why? Let's look at Linux for a moment. You're pretty much guaranteed ash-level scripting at a minimum on the system, but any shell script on the system could potentially be written in more than two dozen scripting languages. Linux networking - are you using net-tools derivatives or iputils derivatives? The syntax isn't identical. Basic commands - GNU or Heirloom? Makes a difference. So even for something as "standard" as a Linux environment, there are a gigantic number of permutations.
This is not a bad thing. Different tools for different needs. It's a very good thing. But if there's nothing to abstract the details, you'd better have a damn good memory. I'm very very good at remembering such trivia, but I would not be capable of going to absolutely any Linux box using well-established tools and be 100% guaranteed a command line environment I could use. Nobody at all is that good.
I am fine for admining most Linuxes, HPUX, Solaris, SunOS, OSF/1, FreeBSD, OpenBSD, VxWorks and about a dozen other Un*x variants and derivatives. But in a real-world environment, to be truly optimal, you SHOULD be looking at 20+ different types of Operating system. Random administration of twenty totally different environments is possible, but you WILL want the basics to be abstracted out. It could be GUI-based, it could be shell scripts. Who cares? I'm not saying the solution has to be graphical, only that it has to be abstract. (By graphical, I'm including ncurses, as you can webmin with links or lynx perfectly well, and linuxconf is still a perfectly viable abstraction layer, albeit just for the one OS.)
The days of single-OS environments (especially "Windows shops") are numbered. It's not a viable model any more. You really can't use a hammer for everything and expect to get the results of a well-equipt craftsman or artisan. The model of the artisan is the model that the IT industry desperately needs to get back to. We are masters of our crafts, we should be respected as such, and we should be at the forefront of eliminating single solutions. Single solutions are BAD. They eliminate your ability to adapt, they restrict your thinking and they make you vulnerable to any flaws or limitations they may have. Since the first days of Open Source, you've never needed to be a prisoner to any method. The methods are YOUR servants, not the other way around.
I remember reading in my Elite pilot's handbook how Thargons had had their fear glands surgically removed, and that was in the 80s!
(The point of MAC is that MAC requires that there be explicit permission given by someone who has the authority to give that permission. It is not implicit, unlike DAC where anything not expressly prohibited is implicitly allowed.)
The encryption thing can be improved on a little, if it is not secret key -or- uses an OTP calculator that only resides on authorized machines. The latter is getting a little into security through obscurity, but still works to a degree if the calculator is any good and the underlying crypto is sufficiently strong. As async encryption is slow, you'd probably want a crypto accelerator, but there are countless such systems. Don't blame the algorithms if you don't want the solutions.
By-the-by, most simple functions can be performed via webmin or some other admin tool, in a way that is platform-agnostic to the user. Well, when the module is written correctly, that is. A number are very poor. However, unless you are doing something that requires specific platform awareness, it should be for the tool to do things in the most effective way for a specific platform.
Administrators - ideally - should know principles, methodologies and other higher-level detail, except when low-level detail adds something of value. Which happens and there's no escaping it. When such low-level detail is needed, you WANT to know the syscalls, the user/kernel sockets, the virtual filesystems that provide direct access to kernel parameters. When you are doing high-level operations, you absolutely do NOT want to be messing at that level. You can't possibly hope to keep a heterogeneous network going if you have to micromanage each platform.
(In fact, most corp networks are very homogeneous because their admins are inept enough TO micromanage and therefore CANNOT cope with having multiple platforms. Remember, no homogeneous system - however good - will ever have the best solution to any of the problems before it. It will be a compromise on everything. Heterogeneous networks can always have optimal solutions for everything, requiring only that you use abstract thinking and abstract mechanisms for all the generic stuff.)
Now, let's look at some of the nastier userland stuff. Glibc is maintained by a fairly closed group, is mission-critical, and is notorious for all kinds of quirks and misbehaviours. Rewriting the C library in Occam, then, makes some sense - what we have is really not very usable, but it's vital that it be so.
X is another one, for much the same reason, however adding in that it's horrible on multithreading. It doesn't have any. See every single b**** discussion on the Linux scheduler - here or anywhere else. Replacing X makes sense, because what we have is unmaintainable at best. Alternatives, such as Berlin, were interesting but suffered from a range of problems - GUIs are not easy to write. Occam, although a pain, at least helps you to make sure the code does what you expect, reliably. Of course, Berlin opting for CORBA may not have been terribly smart - CORBA at the time was too heavy, and even now is heavier than it has any business being. Having said that, the idea of having a distributable GUI does make a lot more sense on modern architectures and modern environments. That, however, isn't the way it's going to get solved.
There is nothing worse than a scientist who fixes the observation to meet their theory, to paraphrase the illustrious but equally fictional Sherlock Holmes.
That was openly discussed when the idea of a Department of Homeland Security was being talked about.