First, the Department of Comedy Appropriations Committee commissions an analysis on the current state of government humor. They appoint a consulting firm to investigate the effectiveness of current jokes, baseline requirements for replacement jokes plus evaluation of the risks of producing new jokes.
This report goes back to the committee who then approve the tender process. The tender duly goes out, where prospective contractors reply with details of past jokes, resumes of key comedy writers and detailed costings for writing of the joke.
The proposals go back to a subcommittee which produces three recommendations to return to the appropriations committee. The recommendations are announced and subjected to three months of public comment. After this, the committee meets again and formulates a single proposal which is then sent to Congress for approval. The proposal sits in committee for three months, during which it is amended to include extra benefits for certain committee members' pet comedic projects. Once approved, the contractor is appointed.
The contractor will almost certainly subcontract out some of the work, of course. If the joke requires a pun, for example, they will work closely with a specialised synophonic engineering corporation. At each stage, of course, the oversight committee must reconvene to approve the new subcontractor and possible budgetary implications.
After six months comes the first deliverable: a detailed design document outlining the scope of the joke, full details on how the joke is to be delivered, any training which the joke's target audience may have to receive beforehand, plus a full analysis of the joke's structure. Once this is approved, the joke moves to the comedy writers, who proceed to write a prototype joke. This is then sent out to simulated audiences where the prototype joke is tested for comedic effectiveness. The results of the tests are sent back to the comedy engineers who then rework the joke.
By this time, the Department of Comedy's Appropriations Secretary has been replaced. When the new secretary reviews the project, they see problems. Certain humorous allusions which are vital to the success of any replacement jokes have not been factored in. The project specifications are changed and new project deadlines are set. The prototype joke is amended, however, in the process, the new joke loses some of its satirical quality. After obtaining approval for more budget, a new quality assurance oversight group is commissioned to audit the joke and the writing process.
Once the new joke has been fully audited, it is ready for field testing. Specialised test comedians are employed to determine the joke's comedic value, plus to determine the most effective mode of delivery under various comedic conditions.
Finally, the joke is delivered, six months late and millions of dollars over budget, along with 26 volumes of JokeSpec-compliant supporting documentation. After a further round of testing by Department of Comedy test comedians, the joke is approved and ready for initial field deployment. At first the joke is used carefully at informal meetings. When problems are found, comedy writers are shipped out on-site to fix minor wording issues.
After six months of this, the joke is ready for prime-time use.
I'd tell you what the joke actually is, but unfortunately I'm under an NDA. Sorry.
I don't have ADD. I have a different condition which my psychologist (who has this condition too) calls "absent-minded professor syndrome".
Basically, I have much, much memory for the abstract, but almost no memory for the concrete. I'm constantly forgetting to turn the car headlights off, where I've put things, appointments, deadlines and so on.
How do you cope with it? Well, I live my entire life in a diary. Everything I need to do gets written down. If I don't have the diary with me, I cross my fingers and am not allowed to uncross them until it goes in the diary. Every day I transfer stuff from one page to the next. It's low-tech, but it works wonders.
The story goes that at school, he got his friends to call him "bitch sex demigod from hell", to which he would always reply "aw, man, don't call me that!" Before long, everyone was teasing him with this name. "Oooh! Bitch sex demigod from hell!"
This has even better possibilities than "Whiffles the Wonder Pig", I reckon.
Ummm... I see absolutely nothing wrong with maintaining my own Linux kernel tree.
Nor do I, but then, I'm generally not the one who counts the beans. If you had to decide whose budget it comes out of, that's a different issue.
So far, I've had very little difficulty finding areas where Linux is perfect for the job [...]
I can name quite a few areas myself. I can also name quite a few where it isn't perfect, but some other solution is. Often, the better solution is also open source.
If the kernel passes muster, it passes muster, and off it goes in its own little boxen.
...until a bug is found, which gets fixed in Linus' and Alan's trees, which you then have to reconcile with your own tree along with everything else that has gone into the kernel in the mean time, or wait for someone else to do it.
There is nothing better, in terms of 'off-the-shelf', than Linux. Unless you mean 'Sales Shelf' [...]
No, by "off the shelf" I mean precisely that combination of qualities which do not oblige you to apply source patches or otherwise maintain your own tree.
There are many ways that Linux can have support for hard real-time scheduling, and some of those ways require the use of one tool: 'patch'.
Unless there's something in Linux that you really need, I suspect that TRON is often going to be easier and cheaper to use than patch. The "patch" approach effectively requires you to maintain your own Linux kernel tree. That has a cost associated with it. If you can get all that you need off-the-shelf from somewhere else, that will probably be better for you in the long run.
Note that I'm not knocking Linux here. I'm a very happy long-time Linux user. However, it's not the most appropriate solution to every problem, especially when there are many other fine open source operating systems out there, several of them designed from the ground-up for real-time embedded systems, of which TRON is but one.
And everything we've wanted to do with TRON, we can now do with Linux.
No we can't. Linux has no support for hard real-time scheduling.
We have a fighting chance of doing some of those things with RTLinux, but even then we might be in a bit of trouble, because of all the indeterminate-latency device drivers.
I don't know who he is (apart from "a lecturer at Stanford"; thanks to Google I am now a little more enlightened).
Everyone who can call themselves a programmer has read at least one Knuth book, though, so simply saying "it's a Knuth book" speaks volumes. Admittedly less so for Ron Graham.
First of all, I explicitly said that the open-sourceness of an OS is at best icing on the cake. All that Linux provides that most other OSes can't is access to commodity hardware with a Unix-like interface at the right price.
Secondly, contrary to common belief, real-world rendering software is not mostly mathematical. I used to work for a certain company which writes rendering software used on such films as The Matrix and Fight Club, and I was as surprised as you to learn this.
A large Pixar-sized frame might have 2Gb of compressed geometry data and 10Gb of compressed texture data in it. The two limiting factors are network bandwidth (moving that much data around a render farm can be a real bottleneck) and memory (while not all 12Gb will be in memory at once, because the rendering software will do a lot of the caching itself, good virtual memory performance is critical).
And remember, of course, that rendering is only the last step in the pipeline. There's modelling, rigging, animation, simulation, lighting and non-graphical tasks like asset management all to take into account.
Under Linux, you can do things that you previously could pretty much only do on SGI. Because it's commodity PC hardware, it's much cheaper, and because it's sufficiently Unix-like, it's very easy to port.
That it's open source is at best icing on the cake.
It also screws royally with your numerics. Take, for example:
float x = something(), y = something_else();
if (x < y) assert(x < y);
This assertion can fail on Intel hardware, because by the time the assert comes around, x may equal y as one or both of them have been truncated from 80 bits to 32.
There's no really hard parts in a functionally complete OS kernel, as can be seen if you look at a simple OS like Minix or Xinu. The device drivers are kinda tricky, of course, but that's mostly because there are so damn many of them.
I'd estimate that it's about an order of complexity harder to write, say, an optimising retargetable C++ compiler. (Though it helps if you have a retargetable C compiler first.) Or perhaps something like Mozilla, though once again it helps if you already have Mosaic and Netscapes 1 through 4.
Leaving asside the figures, that's an odd definition of "worthwhile". Do you actually need to serve 10,000 static web pages per second on one box? Do you need it so much that you're prepared to have your machine's kernel (not just the superuser) compromised if an attacker finds a bug in Tux?
We modularise our machines for a very good reason. Tux is a cool hack, but I'd quietly retask any sysadmin working for me who tried to use it in a production environment. An extra box or two plus a load balancer are a small price to pay if we find we really need more pages per second.
It takes time to animate/simulate/etc the stuff in the first place. (It can take many minutes to do all of the physical simulation required for one second of film frame.)
Network bandwidth, disk speed etc. A large frame might need 2Gb of compressed geometry data and 10Gb of compressed texture data. You simply can't move 24 of those oer secibd around a render farm on current hardware.
What does "photorealistic" mean anyway? You mean when it looks like the real Gollum, or a real talking ant?
The floppy disk driver needs free access to the floppy disk hardware plus whatever abstractions the OS gives it to hand IO upwards.
Unless you write some nasty code, every floppy disk access that you do goes through at least three levels of translation: from user space to kernel space, from the system call layer to the file system layer, and from the file system layer to the block device. There's probably a buffer cache or page cache in there somewhere too. The floppy disk driver and your application are well separated.
I agree with you that address translation is a problem, however, this is mostly a problem with the x86 architecture. The x86 flushes the TLB on every address space switch. If we had a decent tagged TLB, this wouldn't be a problem. Indeed, it isn't a problem on most architectures that QNX is asked to run on. Repeat until enlightened: Context switching is only expensive on the x86 architecture.
The "additional costs" for IPC are mostly an illusion, since we're talking about IPC which is tightly integrated with the kernel, not SysV IPC. Yes, it costs to copy memory, but the cost is there in Linux too; it's just a user space -> kernel space copy rather than a user space -> user space copy.
Having said that, it may be possible to write an OS for which the context switching is much cheaper. L4 uses a neat scheme where a small part of everyone's address space is allocated to other small processes, so context switching only requires a change of segment, rather than a change of address space mapping. IPC is very fast under L4 if you're doing it with a small address space task.
Why would linux kernel hackers be adding tools like HTTP servers and packet filtering into the kernel, if it was somehow the UNIX way to keep them as seperate processes managed by the kernel?
I've wondered that myself. I can only conclude that these projects are either experiments which accidentally escaped the lab, or the hackers who wrote them have no sense of sound software engineering principles.
I think the issue (and I'm sorry I missed the original call for questions, otherwise I would have submitted it) is this:
The RIAA has continually asserted that there is observed correlation between the rise of P2P and a drop in CD sales, and concluded that there is a causal relationship. However, the same years have also seen a drop in the economy, plus a huge rise in sales of newer kinds of media (e.g. DVDs (especially music DVDs) and broadband internet). My question would have been: Is there any hard evidence which shows that the drop in CD sales is substantially due to piracy?
I agree that the original poster put this badly. My point is that the burden of evidence on is on the RIAA to show that piracy is at least partly responsible for the drop in CD sales. There are so many other things that could be responsible that it's not obvious to me.
For the benefit of the non-Americans, what are the peace-/ameri-corps and how do they differ from the millitary?
BTW, I'm a fat bearded geek, which is one of the four major geek types. Would I qualify for any of these? If not, how would I earn the chance to vote under the proposed scheme?
Slashdot Mirror
Hmmm...
Excuse me, I just have to go buy some shares in Parker Brothers...
Thanks a lot. Now we have to sit through months of leak inquiries while we find out who blabbed.
Sigh.
Oh, no. It's way harder than that.
First, the Department of Comedy Appropriations Committee commissions an analysis on the current state of government humor. They appoint a consulting firm to investigate the effectiveness of current jokes, baseline requirements for replacement jokes plus evaluation of the risks of producing new jokes.
This report goes back to the committee who then approve the tender process. The tender duly goes out, where prospective contractors reply with details of past jokes, resumes of key comedy writers and detailed costings for writing of the joke.
The proposals go back to a subcommittee which produces three recommendations to return to the appropriations committee. The recommendations are announced and subjected to three months of public comment. After this, the committee meets again and formulates a single proposal which is then sent to Congress for approval. The proposal sits in committee for three months, during which it is amended to include extra benefits for certain committee members' pet comedic projects. Once approved, the contractor is appointed.
The contractor will almost certainly subcontract out some of the work, of course. If the joke requires a pun, for example, they will work closely with a specialised synophonic engineering corporation. At each stage, of course, the oversight committee must reconvene to approve the new subcontractor and possible budgetary implications.
After six months comes the first deliverable: a detailed design document outlining the scope of the joke, full details on how the joke is to be delivered, any training which the joke's target audience may have to receive beforehand, plus a full analysis of the joke's structure. Once this is approved, the joke moves to the comedy writers, who proceed to write a prototype joke. This is then sent out to simulated audiences where the prototype joke is tested for comedic effectiveness. The results of the tests are sent back to the comedy engineers who then rework the joke.
By this time, the Department of Comedy's Appropriations Secretary has been replaced. When the new secretary reviews the project, they see problems. Certain humorous allusions which are vital to the success of any replacement jokes have not been factored in. The project specifications are changed and new project deadlines are set. The prototype joke is amended, however, in the process, the new joke loses some of its satirical quality. After obtaining approval for more budget, a new quality assurance oversight group is commissioned to audit the joke and the writing process.
Once the new joke has been fully audited, it is ready for field testing. Specialised test comedians are employed to determine the joke's comedic value, plus to determine the most effective mode of delivery under various comedic conditions.
Finally, the joke is delivered, six months late and millions of dollars over budget, along with 26 volumes of JokeSpec-compliant supporting documentation. After a further round of testing by Department of Comedy test comedians, the joke is approved and ready for initial field deployment. At first the joke is used carefully at informal meetings. When problems are found, comedy writers are shipped out on-site to fix minor wording issues.
After six months of this, the joke is ready for prime-time use.
I'd tell you what the joke actually is, but unfortunately I'm under an NDA. Sorry.
I don't have ADD. I have a different condition which my psychologist (who has this condition too) calls "absent-minded professor syndrome".
Basically, I have much, much memory for the abstract, but almost no memory for the concrete. I'm constantly forgetting to turn the car headlights off, where I've put things, appointments, deadlines and so on.
How do you cope with it? Well, I live my entire life in a diary. Everything I need to do gets written down. If I don't have the diary with me, I cross my fingers and am not allowed to uncross them until it goes in the diary. Every day I transfer stuff from one page to the next. It's low-tech, but it works wonders.
I haven't. I've seen the movie, though. I think Charlton Heston was in it.
A man went to a rare book shop and noticed an old bible on display. He struck up a conversation with the book shop owner.
"Yeah, actually, I had an old bible which I threw out last week. It was by someone called Guten... something."
"Not Gutenberg, I hope?"
"Yeah, that's the one."
Upon seeing the look on the book shop owner's face, the man replied:
"Ah, don't worry. It wasn't worth anything. Some guy called Martin had scribbled in it."
This reminds me of an old Jimeoin routine.
The story goes that at school, he got his friends to call him "bitch sex demigod from hell", to which he would always reply "aw, man, don't call me that!" Before long, everyone was teasing him with this name. "Oooh! Bitch sex demigod from hell!"
This has even better possibilities than "Whiffles the Wonder Pig", I reckon.
Nor do I, but then, I'm generally not the one who counts the beans. If you had to decide whose budget it comes out of, that's a different issue.
I can name quite a few areas myself. I can also name quite a few where it isn't perfect, but some other solution is. Often, the better solution is also open source.
...until a bug is found, which gets fixed in Linus' and Alan's trees, which you then have to reconcile with your own tree along with everything else that has gone into the kernel in the mean time, or wait for someone else to do it.
No, by "off the shelf" I mean precisely that combination of qualities which do not oblige you to apply source patches or otherwise maintain your own tree.
Unless there's something in Linux that you really need, I suspect that TRON is often going to be easier and cheaper to use than patch. The "patch" approach effectively requires you to maintain your own Linux kernel tree. That has a cost associated with it. If you can get all that you need off-the-shelf from somewhere else, that will probably be better for you in the long run.
Note that I'm not knocking Linux here. I'm a very happy long-time Linux user. However, it's not the most appropriate solution to every problem, especially when there are many other fine open source operating systems out there, several of them designed from the ground-up for real-time embedded systems, of which TRON is but one.
No we can't. Linux has no support for hard real-time scheduling.
We have a fighting chance of doing some of those things with RTLinux, but even then we might be in a bit of trouble, because of all the indeterminate-latency device drivers.
I don't know who he is (apart from "a lecturer at Stanford"; thanks to Google I am now a little more enlightened).
Everyone who can call themselves a programmer has read at least one Knuth book, though, so simply saying "it's a Knuth book" speaks volumes. Admittedly less so for Ron Graham.
Knuth, Graham and Patashnik, Concrete Mathematics.
Mind you, with Don Knuth and Ron Graham's names in the author list is going to be good. :-)
You think that the T-Shirt Association of America would let a little thing like which state you're in prevent them from releasing the lawyers?
First of all, I explicitly said that the open-sourceness of an OS is at best icing on the cake. All that Linux provides that most other OSes can't is access to commodity hardware with a Unix-like interface at the right price.
Secondly, contrary to common belief, real-world rendering software is not mostly mathematical. I used to work for a certain company which writes rendering software used on such films as The Matrix and Fight Club, and I was as surprised as you to learn this.
A large Pixar-sized frame might have 2Gb of compressed geometry data and 10Gb of compressed texture data in it. The two limiting factors are network bandwidth (moving that much data around a render farm can be a real bottleneck) and memory (while not all 12Gb will be in memory at once, because the rendering software will do a lot of the caching itself, good virtual memory performance is critical).
And remember, of course, that rendering is only the last step in the pipeline. There's modelling, rigging, animation, simulation, lighting and non-graphical tasks like asset management all to take into account.
Under Linux, you can do things that you previously could pretty much only do on SGI. Because it's commodity PC hardware, it's much cheaper, and because it's sufficiently Unix-like, it's very easy to port.
That it's open source is at best icing on the cake.
It also screws royally with your numerics. Take, for example:
This assertion can fail on Intel hardware, because by the time the assert comes around, x may equal y as one or both of them have been truncated from 80 bits to 32.
Really?
There's no really hard parts in a functionally complete OS kernel, as can be seen if you look at a simple OS like Minix or Xinu. The device drivers are kinda tricky, of course, but that's mostly because there are so damn many of them.
I'd estimate that it's about an order of complexity harder to write, say, an optimising retargetable C++ compiler. (Though it helps if you have a retargetable C compiler first.) Or perhaps something like Mozilla, though once again it helps if you already have Mosaic and Netscapes 1 through 4.
Leaving asside the figures, that's an odd definition of "worthwhile". Do you actually need to serve 10,000 static web pages per second on one box? Do you need it so much that you're prepared to have your machine's kernel (not just the superuser) compromised if an attacker finds a bug in Tux?
We modularise our machines for a very good reason. Tux is a cool hack, but I'd quietly retask any sysadmin working for me who tried to use it in a production environment. An extra box or two plus a load balancer are a small price to pay if we find we really need more pages per second.
Some thoughts on limitations:
The floppy disk driver needs free access to the floppy disk hardware plus whatever abstractions the OS gives it to hand IO upwards.
Unless you write some nasty code, every floppy disk access that you do goes through at least three levels of translation: from user space to kernel space, from the system call layer to the file system layer, and from the file system layer to the block device. There's probably a buffer cache or page cache in there somewhere too. The floppy disk driver and your application are well separated.
I agree with you that address translation is a problem, however, this is mostly a problem with the x86 architecture. The x86 flushes the TLB on every address space switch. If we had a decent tagged TLB, this wouldn't be a problem. Indeed, it isn't a problem on most architectures that QNX is asked to run on. Repeat until enlightened: Context switching is only expensive on the x86 architecture.
The "additional costs" for IPC are mostly an illusion, since we're talking about IPC which is tightly integrated with the kernel, not SysV IPC. Yes, it costs to copy memory, but the cost is there in Linux too; it's just a user space -> kernel space copy rather than a user space -> user space copy.
Having said that, it may be possible to write an OS for which the context switching is much cheaper. L4 uses a neat scheme where a small part of everyone's address space is allocated to other small processes, so context switching only requires a change of segment, rather than a change of address space mapping. IPC is very fast under L4 if you're doing it with a small address space task.
I've wondered that myself. I can only conclude that these projects are either experiments which accidentally escaped the lab, or the hackers who wrote them have no sense of sound software engineering principles.
I think the issue (and I'm sorry I missed the original call for questions, otherwise I would have submitted it) is this:
The RIAA has continually asserted that there is observed correlation between the rise of P2P and a drop in CD sales, and concluded that there is a causal relationship. However, the same years have also seen a drop in the economy, plus a huge rise in sales of newer kinds of media (e.g. DVDs (especially music DVDs) and broadband internet). My question would have been: Is there any hard evidence which shows that the drop in CD sales is substantially due to piracy?
I agree that the original poster put this badly. My point is that the burden of evidence on is on the RIAA to show that piracy is at least partly responsible for the drop in CD sales. There are so many other things that could be responsible that it's not obvious to me.
For the benefit of the non-Americans, what are the peace-/ameri-corps and how do they differ from the millitary?
BTW, I'm a fat bearded geek, which is one of the four major geek types. Would I qualify for any of these? If not, how would I earn the chance to vote under the proposed scheme?
The Simpsons has a quote for every occasion.
You misspelled "freedom". Hope this helps.