I think we're going to see languages move in two directions: higher and wider.
The "higher" languages will be designed for bigger abstractions. A lot of these will compile down to today's high- and medium-level languages. Most will be domain-specific. We've always had examples of this (e.g. parser compilers such as yacc, ASN.1 compilers and so on; there are plenty of these for high-level languages like Haskell, such as happy and Strafunski too), but I think we'll see more as we go on.
The "wider" languages will be designed to support higher-level abstractions directly by providing the basic building blocks to the library writer. We see this in C++ template libraries, Haskell combinator libraries, Lisp macro libraries and so on. They will not be as good as "high" languages in their specific domains, but they will be generic enough for "normal" applications, plus they will have the benefit of not requiring a whole other compi.
You are confusing free as in time with free as in beer.
BSD-licensed software is not merely released at no cost, it is released with no strings attached. This is free as in "free time" rather than "free beer" (a lot of proprietary software is released at no cost) or "free speech" (copyleft).
You said "Don't steal my code then". That's fine for your code and mine (despite the abuse of the software and property analogy concept of "stealing"), but I don't think it even makes sense to talk about taxpayers "stealing" government code, since they paid for it in the first place.
I think you missed the point. All of this
guy's victims never saw him coming. Assuming
this was his intention, a smart criminal would reason
that whether his victims were armed or not would
make no difference.
This is, of course, assuming that criminals
actually do a cost-benefit analysis first.
There are many good arguments for having an armed
populace, but this is not one of them.
I agree that so far, Pixar films have not used,
and did not need, GI. Pixar also concedes that
PRMan version 11's GI/ray tracing support will not
be ready for "prime time". It's only a matter of
time, though. Animated movies with ray tracing
and GI are being done for the first time now,
and Pixar had better have a good implementation
of both ready for when it does finally become an
issue. That, IMO, is why they're putting it in now.
PDI's renderer (at least the one used on Antz
and Shrek; they're rewriting it for the next
film) does not use GI but it does support ray
tracing. Pixar used a small amount of ray tracing
(with BMRT, no less) in A Bug's Life. So
this feature, at least, will almost certainly be
used more over the next decade.
Incidentally, I used to work for Dot C, so I
have a pretty good idea what people want from
Pixar's competitors.:-)
The software market is not the only market that Pixar competes in.
Remember that the commercial version of PRMan is exactly the same one that they use to make their own movies. Unless someone with an awful lot of money wanted raytracing and GI, there are only two reasons why Pixar would add them. 1) They wanted another check-point for the "product features" list, or 2) They wanted to use it themselves. Given that there is someone else making feature animations now with a GI-capable renderer, the latter is the more likely explanation (IMO).
This seems to have been in response to Exluna's Entropy before it's demise [...]
I keep hearing this claim. Don't you think that it might also have something to do with the entry of Blue Sky Studios (and their ray tracing/GI renderer) into the feature animation club?
RenderMan is not like POVRay. It's an algorithm neutral interface between modellers and renderers. The idea is that whether your renderer is a REYES-esque scanline renderer, a raytracer, a Monte Carlo radiosity raytracer or whatever, your file should still work.
That means that sometimes the modeller has to do a lot of work which in some renderer algorithms would be done for you. For example, in a REYES renderer, reflections are done with multiple render passes, just like in OpenGL. The modeller has to emit RenderMan code to do these multiple passes. In a raytracer, this would be done for you, but you would have to retain all of the scene geometry in memory, plus you lose coherency. (Most animation/visual effects scenes do not use raytracing for this reason. It's just too damn slow for "real" scenes.)
That's one reason why good Maya -> RenderMan interfaces are worth quite a lot of money (MTOR is US$3k).
Aqsis is a GPL'd RenderMan-compliant REYES renderer. Liquid is now open source. All it takes is a good open source modeller (disclaimer: I don't know if Blender is "good" enough for this kind of use) and we're in business.
Re:Posting this anonymously to save my fragile kar
on
The End Of Minix?
·
· Score: 2
As operagost noted, NT 3 was a microkernel OS
and NT 4 was not. (A 14Mb kernel is not "micro"
by anyone's standard.) I believe (I may recall
this incorrectly) the main thing they did was
import the GDI subsystem into the kernel to
improve multimedia performance in NT Workstation,
and used the same setup in NT Server despite the
fact that servers do not generally need multimedia
performance.
BeOS is a microkernel. Servers can
run in user space (though you can optionally load
them in kernel space too) and only communicate
with the kernel via system calls.
If BeOS isn't a microkernel, then neither is
QNX because of the "back door" hooks that the
process manager gets to use.
Heh, good luck. He's going to need a miracle
in the face of all those people switching
to Windows.
Re:If Linus were Homer...
on
The End Of Minix?
·
· Score: 5, Interesting
The ironic thing is that Tanenbaum's argument
is now correct, even though it was not ten years
ago.
Nobody would now would make a new
monolithic kernel if they were in their
right minds. However, nobody now would
make a new Mach-alike if they were in their right
minds either. Microkernels have finally proven
themselves to be up to the job of being the basis
of serious operating systems (e.g. BeOS, QNX,
ChorusOS etc), but they're not the kinds of
microkernels that Tanenbaum was advocating in
1992. Microkernels of the time spent far too
much time shifting data between servers,
whereas modern microkernels a) do at most as much
address-space shifting as a monolithic kernel,
plus b) they're even more "micro".
Then how do you explain the ui of
every in house 3d tool in the industry?
They're designed for fast workflow, relative to
the way that house works.
Incidentally, most current in-house tools are
packages built on top of a commercial system like
Maya or Houdini. The key here is that you can
customise such a tool to suit your own workflow.
Any system which does not support this
runs the risk of being a toy.
Re:Bitch'n moan about the UI...
on
Blender Is GPL
·
· Score: 2
People who find the UI difficult to
use remind me of people who can't read sheet music
bitching about how hard it is to play the
violin.
More like people who can read Western sheet
music bitching about how hard it is to play music
notated in MusicTeX or Lilypond.
I used to get paid to use Maya and I find
Blender clunky. (But then, I find 3DS Max, which
I also got paid to use, clunky too.)
Alternatively, the threads library could be made as easy to use as the older unix approach.
Well there are a lot of very nice wrappers out
there (e.g. boost::thread, QThread and so on), plus
most serious applications have their own wrappers.
This is the same reason, incidentally, why
developers generally don't use open(), read(),
write() and creat(): that's not the level you're
meant to program at. You should use stdio,
sfio or iostreams instead, unless you really
need the finer control.
One real reason, I think, why we don't see more threads
under Linux is that Linux doesn't support POSIX
threads. The POSIX threads model is processes
which have threads. Linux, on the other hand, has
processes which can share address spaces, file
descriptors and so on, which is not the same thing.
For example, fork()ing a process in one thread
and waitpid()ing on it in another thread simply
doesn't work under Linux. This sort of thing
makes porting POSIX-compliant multithreaded
applications to Linux difficult at best.
Note: Before anyone accuses me of FUDing, note
that I'm not passing value judgements here. Linux
threads might well be better than POSIX threads.
As a developer, however, when I #include
<pthread.h>, I expect POSIX threads, and
under Linux I don't get that. It's the lie that
concerns me.
I won't even go into the overhead inherent in a micro kernel message passing architecture.
Just as well, because you'd be shocked to find
out that it's no more expensive than in a
monolithic kernel.
The Hurd currently uses Mach, which is an "old"
microkernel design, so you would be correct in
noting that Mach's message passing is expensive.
Not so in a modern microkernel, such as QNX or L4.
They don't use SysV IPC to communicate; message
passing is an OS primitive, and the building block
on which all other communication is based. As such,
they go to a lot of trouble to optimise it, copying
data directly between the address space of the
sender and the address space of the receiver, which
is very cheap.
Monolithic kernels, on the other hand, do not
copy large slabs of data between user space and
user space. Insetad, they copy large slabs of
data between user space and kernel space. A few
moments' thought should be sufficient to convince
you that the cost in each case is the same.
This article has one selling point: The Hurd
has POSIX threads. Linux doesn't.
I'm not kidding and this is not FUD. You try
fork()ing a process in one thread and wait()ing
for it in another thread if you don't believe
me.
Ship of Fools
held a competition some time ago. The results
are highly amusing. For the record, the winner was:
dad@hvn,ur spshl.we want wot u want&urth2b like hvn.giv us food&4giv r sins lyk we 4giv uvaz.don't test us!save us!bcos we kno ur boss,ur tuf&ur cool 4 eva!ok?
Not only is it l33t-ed, it's under 160 characters,
and thus suitable for transmission via SMS.
It's kind of odd that all of the pioneers
of film computer graphics knew someone who worked
on Tron. It's almost like that film
ruined the careers of everyone who worked on it,
but started the careers of everyone who knew
somebody who worked on it.
That's why Al Qaeda hit us instead of Israel. That's why we continue to be a target - our freedom scares the hell out of them.
Al Qaeda did not hit Israel
because a) nobody would have noticed another
terror attack in Israel, and b) it's not Israeli
forces that are currently camped in Saudi
Arabia. Saying "they hate our freedom" is a good
piece of propaganda on Bush's part, but
essentially it's the old "they're evil and we're
not" xenophobic argument thinly veneered.
The US, of course, did not deserve any of this.
No country deserves to have thousands of its
citizens killed by a bunch of whackos. However,
it's not freedom which scares the terrorists.
I would think that very little scares the
terrorists.
Whether there is a performance
penalty to such wrapping is hard to say.
Generally, there will be some performance penalty
for the "indirection" needed for hiding
implementation. [...] Some programmers get obsessive over speed for no good reason, and make stupid (change-unfriendly) code as a result.
Repeat until enlightened: Unless you
have an unlimited amount of programmer time to
expend, long-term performance is a consequence of
maintainability.
The "big" performance improvements are
generally algorithmic in nature. They're what you
get when you replace an O(N^2) algorithm with an
O(N log N) algorithm, or when you replace an
O(N log N) algorithm with an O(N log N log log N)
algorithm which exploits cache coherency much
better.
When you find that you
need to change one algorithm or data structure
with another (and you will), you might think
twice before doing that to an unencapsulated
implementation, whereas doing it to an
encapsulated implementation will be much
cheaper. Moreover, with an encapsulated
implementation, you can play with several
different implementations until you find the
best one for the situation at hand.
Yes, your code may have perform better had you
written an unencapsulated version of the most
appropriate algorithm/data structure to begin
with. What a wonderful world it would be if
software engineers were also clairvoyants.:-)
(BTW, you don't need OOP to wrap
collection handlers.)
No, you don't. You at least need abstraction
and at most you need encapsulation. These
are a subset of the problems that OOP solves, but
OOP is not the only solution to those problems.
So while you don't need OOP, if you're working
with a system which already has it, you might as
well use it unless there's a good reason not
to.
I don't expect my parents to
understand or at least be able to make any
informed decision on the nature of open-source
versus proprietary software [...]
No, and nor should they. I don't expect my
parents to understand the details of Australia's
extradition treaty with Latvia, either. Hell, I
don't expect myself to understand them.
That's what representational democracy and a
competent public sector is supposed to be
about. I elect experts and people who hire
experts so that I don't have to be an expert
myself.
Mind you, having worked in the Australian public
service, I don't expect public sector IT managers
to make informed decisions either, but that's a
slightly different issue. This is not necessarily
because IT managers are incompetent, though some
are. It's because they're under so many artificial
constraints as it is, both legal and political,
that they often can't even try to find the most
appropriate solution for some problem. The
situation would be no better were they forced to
use open source internally, because that would
just be another artificial constraint.
Governments do not have to use open source
unless the people say they must. Our
governments are indeed executors of the will of
the people, however they are also the stewards of
taxpayers' money. If open source does not win in
the cost-benefit analysis (particularly the
"benefit" part of the equation), then open source
should not be used.
IMO, the more important issue, and one I think which
came out in the Peruvian letter, is this:
Governments must not force citizens to use
proprietary software to interact with their
government. This means that, for example, a
government department may use Microsoft Word to
store its internal documents, but published
documents must be in an open format (e.g. PDF).
Similarly, your taxation officials may use IIS to
run their web site, but must not require you to
use IE in order to file your tax returns
electronically.
Slashdot Mirror
OK, wild speculation follows...
I think we're going to see languages move in two directions: higher and wider.
The "higher" languages will be designed for bigger abstractions. A lot of these will compile down to today's high- and medium-level languages. Most will be domain-specific. We've always had examples of this (e.g. parser compilers such as yacc, ASN.1 compilers and so on; there are plenty of these for high-level languages like Haskell, such as happy and Strafunski too), but I think we'll see more as we go on.
The "wider" languages will be designed to support higher-level abstractions directly by providing the basic building blocks to the library writer. We see this in C++ template libraries, Haskell combinator libraries, Lisp macro libraries and so on. They will not be as good as "high" languages in their specific domains, but they will be generic enough for "normal" applications, plus they will have the benefit of not requiring a whole other compi.
You are confusing free as in time with free as in beer.
BSD-licensed software is not merely released at no cost, it is released with no strings attached. This is free as in "free time" rather than "free beer" (a lot of proprietary software is released at no cost) or "free speech" (copyleft).
You said "Don't steal my code then". That's fine for your code and mine (despite the abuse of the software and property analogy concept of "stealing"), but I don't think it even makes sense to talk about taxpayers "stealing" government code, since they paid for it in the first place.
I think you missed the point. All of this guy's victims never saw him coming. Assuming this was his intention, a smart criminal would reason that whether his victims were armed or not would make no difference.
This is, of course, assuming that criminals actually do a cost-benefit analysis first.
There are many good arguments for having an armed populace, but this is not one of them.
I agree that so far, Pixar films have not used, and did not need, GI. Pixar also concedes that PRMan version 11's GI/ray tracing support will not be ready for "prime time". It's only a matter of time, though. Animated movies with ray tracing and GI are being done for the first time now, and Pixar had better have a good implementation of both ready for when it does finally become an issue. That, IMO, is why they're putting it in now.
PDI's renderer (at least the one used on Antz and Shrek; they're rewriting it for the next film) does not use GI but it does support ray tracing. Pixar used a small amount of ray tracing (with BMRT, no less) in A Bug's Life. So this feature, at least, will almost certainly be used more over the next decade.
Incidentally, I used to work for Dot C, so I have a pretty good idea what people want from Pixar's competitors. :-)
The software market is not the only market that Pixar competes in.
Remember that the commercial version of PRMan is exactly the same one that they use to make their own movies. Unless someone with an awful lot of money wanted raytracing and GI, there are only two reasons why Pixar would add them. 1) They wanted another check-point for the "product features" list, or 2) They wanted to use it themselves. Given that there is someone else making feature animations now with a GI-capable renderer, the latter is the more likely explanation (IMO).
I keep hearing this claim. Don't you think that it might also have something to do with the entry of Blue Sky Studios (and their ray tracing/GI renderer) into the feature animation club?
Not true.
RenderMan is not like POVRay. It's an algorithm neutral interface between modellers and renderers. The idea is that whether your renderer is a REYES-esque scanline renderer, a raytracer, a Monte Carlo radiosity raytracer or whatever, your file should still work.
That means that sometimes the modeller has to do a lot of work which in some renderer algorithms would be done for you. For example, in a REYES renderer, reflections are done with multiple render passes, just like in OpenGL. The modeller has to emit RenderMan code to do these multiple passes. In a raytracer, this would be done for you, but you would have to retain all of the scene geometry in memory, plus you lose coherency. (Most animation/visual effects scenes do not use raytracing for this reason. It's just too damn slow for "real" scenes.)
That's one reason why good Maya -> RenderMan interfaces are worth quite a lot of money (MTOR is US$3k).
Aqsis is a GPL'd RenderMan-compliant REYES renderer. Liquid is now open source. All it takes is a good open source modeller (disclaimer: I don't know if Blender is "good" enough for this kind of use) and we're in business.
As operagost noted, NT 3 was a microkernel OS and NT 4 was not. (A 14Mb kernel is not "micro" by anyone's standard.) I believe (I may recall this incorrectly) the main thing they did was import the GDI subsystem into the kernel to improve multimedia performance in NT Workstation, and used the same setup in NT Server despite the fact that servers do not generally need multimedia performance.
BeOS is a microkernel. Servers can run in user space (though you can optionally load them in kernel space too) and only communicate with the kernel via system calls.
If BeOS isn't a microkernel, then neither is QNX because of the "back door" hooks that the process manager gets to use.
Heh, good luck. He's going to need a miracle in the face of all those people switching to Windows.
The ironic thing is that Tanenbaum's argument is now correct, even though it was not ten years ago.
Nobody would now would make a new monolithic kernel if they were in their right minds. However, nobody now would make a new Mach-alike if they were in their right minds either. Microkernels have finally proven themselves to be up to the job of being the basis of serious operating systems (e.g. BeOS, QNX, ChorusOS etc), but they're not the kinds of microkernels that Tanenbaum was advocating in 1992. Microkernels of the time spent far too much time shifting data between servers, whereas modern microkernels a) do at most as much address-space shifting as a monolithic kernel, plus b) they're even more "micro".
They're designed for fast workflow, relative to the way that house works.
Incidentally, most current in-house tools are packages built on top of a commercial system like Maya or Houdini. The key here is that you can customise such a tool to suit your own workflow. Any system which does not support this runs the risk of being a toy.
More like people who can read Western sheet music bitching about how hard it is to play music notated in MusicTeX or Lilypond.
I used to get paid to use Maya and I find Blender clunky. (But then, I find 3DS Max, which I also got paid to use, clunky too.)
It's actually an odd combination of continuous and discrete mathematcs, hence Concrete Mathematics.
Well there are a lot of very nice wrappers out there (e.g. boost::thread, QThread and so on), plus most serious applications have their own wrappers. This is the same reason, incidentally, why developers generally don't use open(), read(), write() and creat(): that's not the level you're meant to program at. You should use stdio, sfio or iostreams instead, unless you really need the finer control.
One real reason, I think, why we don't see more threads under Linux is that Linux doesn't support POSIX threads. The POSIX threads model is processes which have threads. Linux, on the other hand, has processes which can share address spaces, file descriptors and so on, which is not the same thing. For example, fork()ing a process in one thread and waitpid()ing on it in another thread simply doesn't work under Linux. This sort of thing makes porting POSIX-compliant multithreaded applications to Linux difficult at best.
Note: Before anyone accuses me of FUDing, note that I'm not passing value judgements here. Linux threads might well be better than POSIX threads. As a developer, however, when I #include <pthread.h>, I expect POSIX threads, and under Linux I don't get that. It's the lie that concerns me.
Just as well, because you'd be shocked to find out that it's no more expensive than in a monolithic kernel.
The Hurd currently uses Mach, which is an "old" microkernel design, so you would be correct in noting that Mach's message passing is expensive. Not so in a modern microkernel, such as QNX or L4. They don't use SysV IPC to communicate; message passing is an OS primitive, and the building block on which all other communication is based. As such, they go to a lot of trouble to optimise it, copying data directly between the address space of the sender and the address space of the receiver, which is very cheap.
Monolithic kernels, on the other hand, do not copy large slabs of data between user space and user space. Insetad, they copy large slabs of data between user space and kernel space. A few moments' thought should be sufficient to convince you that the cost in each case is the same.
This article has one selling point: The Hurd has POSIX threads. Linux doesn't. I'm not kidding and this is not FUD. You try fork()ing a process in one thread and wait()ing for it in another thread if you don't believe me.
Ship of Fools held a competition some time ago. The results are highly amusing. For the record, the winner was:
Not only is it l33t-ed, it's under 160 characters, and thus suitable for transmission via SMS.
I submitted a request to give it slashbox status.
Here's hoping...
It's kind of odd that all of the pioneers of film computer graphics knew someone who worked on Tron. It's almost like that film ruined the careers of everyone who worked on it, but started the careers of everyone who knew somebody who worked on it.
Not so long ago, the practice of "duelling" was perfectly legal. Nowadays this would be considered murder.
Al Qaeda did not hit Israel because a) nobody would have noticed another terror attack in Israel, and b) it's not Israeli forces that are currently camped in Saudi Arabia. Saying "they hate our freedom" is a good piece of propaganda on Bush's part, but essentially it's the old "they're evil and we're not" xenophobic argument thinly veneered.
The US, of course, did not deserve any of this. No country deserves to have thousands of its citizens killed by a bunch of whackos. However, it's not freedom which scares the terrorists. I would think that very little scares the terrorists.
Repeat until enlightened: Unless you have an unlimited amount of programmer time to expend, long-term performance is a consequence of maintainability.
The "big" performance improvements are generally algorithmic in nature. They're what you get when you replace an O(N^2) algorithm with an O(N log N) algorithm, or when you replace an O(N log N) algorithm with an O(N log N log log N) algorithm which exploits cache coherency much better.
When you find that you need to change one algorithm or data structure with another (and you will), you might think twice before doing that to an unencapsulated implementation, whereas doing it to an encapsulated implementation will be much cheaper. Moreover, with an encapsulated implementation, you can play with several different implementations until you find the best one for the situation at hand.
Yes, your code may have perform better had you written an unencapsulated version of the most appropriate algorithm/data structure to begin with. What a wonderful world it would be if software engineers were also clairvoyants. :-)
No, you don't. You at least need abstraction and at most you need encapsulation. These are a subset of the problems that OOP solves, but OOP is not the only solution to those problems.
So while you don't need OOP, if you're working with a system which already has it, you might as well use it unless there's a good reason not to.
No, and nor should they. I don't expect my parents to understand the details of Australia's extradition treaty with Latvia, either. Hell, I don't expect myself to understand them. That's what representational democracy and a competent public sector is supposed to be about. I elect experts and people who hire experts so that I don't have to be an expert myself.
Mind you, having worked in the Australian public service, I don't expect public sector IT managers to make informed decisions either, but that's a slightly different issue. This is not necessarily because IT managers are incompetent, though some are. It's because they're under so many artificial constraints as it is, both legal and political, that they often can't even try to find the most appropriate solution for some problem. The situation would be no better were they forced to use open source internally, because that would just be another artificial constraint.
Governments do not have to use open source unless the people say they must. Our governments are indeed executors of the will of the people, however they are also the stewards of taxpayers' money. If open source does not win in the cost-benefit analysis (particularly the "benefit" part of the equation), then open source should not be used.
IMO, the more important issue, and one I think which came out in the Peruvian letter, is this: Governments must not force citizens to use proprietary software to interact with their government. This means that, for example, a government department may use Microsoft Word to store its internal documents, but published documents must be in an open format (e.g. PDF). Similarly, your taxation officials may use IIS to run their web site, but must not require you to use IE in order to file your tax returns electronically.