You want to get rid of the DMCA altogether?
So let me get this straight... you want to make it once
again illegal to install copyrighted system recovery
software on someone's machine for the purposes of fixing it?
You want to make it once again illegal to allow access
copyrighted web content through a proxy (which before the
DMCA was technically "republishing")?
It's only the anticircumvention provisions of the DMCA
(Chapter 12) which are even controversial. There are very
good reasons to keep the rest of the DMCA.
Re:Not just better playback
on
Film Gimp
·
· Score: 2
Pixels are not square, or even rectangular, any more than
a number in a sound file is an interval of time. A pixel is
a point sample, which can be resampled into square areas
if needed.
This is all explained in Alvy Ray Smith's
technical memo.
Read it and consider yourself enlightened.
Re:Not just better playback
on
Film Gimp
·
· Score: 3, Informative
That's quite untrue. What it does is reduce the impact of rounding errors.
Which is highly misleading. What 16 bits per channel
really gives you is more dynamic range.
We CRT users are used to going from black (electron gun
turned as far down as possible) to white (electron gun turned
up as far as possible). "White" for us is a certain point
on the black body radiation curve at a certain intensity.
Film users know that this is not the maximum number of
photons which are available. In real life, you can always
add more. On film, you can usually only add about 20 times
more before it's fully exposed, but it's still more, and it's
noticeable on specular highlights, such as on chrome or
water.
Cineon digital negatives specify 10 bits per channel in
logarithmic space, which appears to be sufficient for
capturing the high dynamic range. Converting this into
linear space (which is more convenient for manipulation)
corresponds to about 16 bits, about 12 bits of which (i.e.
the range 0-4096) are what we think of as the black to
white range. The rest is "headroom" for those times you
need the full dynamic range.
Most people, even those in the industry, do. IMO,
South Park is the very embodiment of
photorealism: The characters look like realistic
cartridge paper cutouts.
Ah, but the original poster won't be doing anything
serious to start with, as they'll be spending most of their
time learning the tools.
The beauty of Aqsis is not that it is production-ready,
but that it gets you started for free while also providing a
clean upgrade path. While you're learning how to use Maya,
Liquid and RenderMan SL, you can start producing real images
and when you're ready, either Aqsis will be suitable for
what you want to do (probably not, but you never know), or
you can get a copy of something else and just drop it in,
taking all the RenderMan(tm) knowledge with you.
First thing, you should be careful with your terminology.
A modeller lets you create models and scenes.
A renderer turns these scenes into 2D images.
A compositor lets you turn these 2D images into
other 2D images, and usually also lets you assemble them
into single-file animation formats.
Don't expect to do any "real" 3D work without at least one
of each.
It's confusing because many modellers have renderers
built in. They are usually inadequate for complex jobs.
(Though, in fairness, one blockbuster 100% computer animated
feature film has been made using Maya's built-in renderer,
so it's not exactly useless.) However, thanks to the
wonders of Open Source, the modeller is now the only part
you have to buy.
Here's what I suggest:
Get Maya Complete. This will cost money.
Get Liquid,
which will cost you nothing. This will export Maya to
RenderMan(TM).
Get Aqsis, which will
cost you nothing. This is your renderer. It is RenderMan(tm)
compliant, which is the de facto standard for
communication between renderers and modellers.
Get Cinelerra,
which will cost you nothing. This is your compositor.
(Available only for Linux, unfortunately, but it's free.)
If you find yourself making money with these, you
can replace and augment bits if you find them not
doing what you want. (For example, replace Aqsis with
RDC or
PRMan
and replace Cinelerra with Shake
or After Effects.
You can even augment Maya with
Houdini or
SoftImage if you
feel like spending money.)
The key here is to stick with standards so you can drop in
replacements into your production line.
No it is not possible. An aeroplane is private
property. Even if the government did not set
rules, you would still have no rights apart from
those which the owner of the plane allowed you to
have. If you don't like it, you are perfectly
within your rights to take your car instead.
Repeat until enlightened: Guns don't protect
freedom, people protect freedom.
Linus was right at the time, yes. If he were
starting Linux today, however, none of those three
points would be correct. They're not
experimental any more (WinNT before version 4.0,
QNX and BeOS are/were all mainstream microkernel
OSes), they do not execute notably slower than
monolithic kernels (yeah, the Mindcraft survey was
rigged, but Linux and NT are still competitive)
and (apart from NT) they are no more
complex than Linux is today.
On the other hand, "I know I can do it and get
it working" would still be a valid argument for
him to write a monolithic kernel today, but that's
open source for you.
A monolithic kernel has no fewer layers than a
modern microkernel OS. Say you want to write to a
file. You make a system call, which goes through
the system call interface layer, which then goes to
the read() system call implementation, which then
goes to the disk subsystem, which then goes to the
disk driver.
"But microkernel OSes have to copy stuff around
between subsystems", I hear you say. Well that's
true under Linux too. At the very least you have
to copy the data from user space to kernel space.
Compare this with a modern microkernel system
where the data is copied straight between your
user space and the disk server's user space. Same
number of layers, same amount of copying.
Having said, that I agree with you that Mach
can't possibly be as fast as, say, Linux, which is
why I carefully said this applied to "modern"
microkernel systems, such as QNX. So my hopes aren't
high for the Hurd, at least in its current
incarnation. However, modern microkernel systems
which run as fast as modern monolithic kernel
systems are here today and they work.
Are you volunteering to do the port of
the ~300kloc mentioned while still supporting
older versions?
Unfortunately, in the real world, rewriting 80%
of the whole system is almost never an option.
The product I am paid to hack on is about
1.5Mloc. While this is bigger than the
original poster's system, we've only ported to
four platforms (32-bit Solaris, 64-bit Solaris,
32-bit Windows 2000 and IA64 Linux), so I
suspect the headache level turns out to be about
the same.
Not really, but thanks for the pointer. Generally, good sequencers don't make good music typesetters in much the same way that vim or emacs doesn't make a good LaTeX.
Well I don't use any of those, but what I really want is a Linux Finale-alike. (Or, even better, something like Finale which supports multiple movements.) Nobody, as far as I know, is currently working on anything even close to this.
There are several key features of an RTOS which Windows 3.1 does not have.
One is pre-emptability. If an event happens which would cause a higher-priority task to run, it must run within a bounded amount of time.
Another related property is low interrupt delivery latency. If a high-priority interrupt occurs, even if a lower-priority interrupt handler is already running, it should be delivered within a bounded amount of time. This is guaranteed by arranging that nobody disables interrupts for an unbounded amount of time. Indeed, under QNX, interrupt handlers are run with interrupts initially enabled.
No he didn't. He said that OO design is not an
indication that software engineering is
mature.
Software engineering certainly has a long way
to go, but OO has brought it for quite
a bit of the distance that it has come in the
last ten or so years, particularly in medium-to-large
scale heterogenous distributed systems (which would
be the sorts of systems that IBM Global Services
are particularly interested in). The object
has turned out to be almost exactly the Right
Thing to model a software component, be it
written in the same or a different language,
or whether or not it lives on a different machine.
We're not even talking about OO languages,
necessarily, just OO design.
It depends on the server. Serving streaming
media is a fundamentally real-time job, for
example. So is ATM switching, not that most
servers have an ATM NIC, of course.
The fastest algorithm is always going to be the one which exploits known features of the data. For example, if you know your data is almost sorted, insertion sort will beat heap sort any time, though merge sort will probably do even better, if you can generate initial runs cleverly.
The second fastest algorithm is the one which can recognise common cases and optimise for them, and fall back to a reasonably efficient general algorithm if necessary.
Incidentally, constant factors really matter, especially on modern machines where you have to take into account virtual memory working sets, buffer cache algorithms, cache coherency and so on. An O(N) algorithm with lots of mutex locking (even if there's no contention) may run significantly slower than an O(N log N) algorithm with not as much locking, simply because of the cost of cache synchronisation.
In the non-realtime graphics industry (I used to work in visual effects), they have an equal and opposite law to Moore's Law known as Blinn's Law. It states that the expectation of audiences rises at the same rate as hardware speed increases, making the amount of time taken to compute a frame basically constant.
I no longer work in visual effects. I now hack a Z39.50 server for a living, and the same is true. Machines get faster, but the amount of text that people want to index increases at the same (or greater) speed.
Note that this doesn't negate your point. My desktop machine spends most of its time waiting for me to press the next key (though it does get a lot of protein folding in while it's waiting). However, Moore's Law is rarely a saving grace, especially on the high end.
Slashdot Mirror
24 hours of silence has probably been copyrighted by Mike Batt by now.
For $DEITY's sake, don't tell anyone! Tim Tams are Australia's best kept secret and we intent to keep it that way.
You want to get rid of the DMCA altogether? So let me get this straight... you want to make it once again illegal to install copyrighted system recovery software on someone's machine for the purposes of fixing it? You want to make it once again illegal to allow access copyrighted web content through a proxy (which before the DMCA was technically "republishing")?
It's only the anticircumvention provisions of the DMCA (Chapter 12) which are even controversial. There are very good reasons to keep the rest of the DMCA.
Pixels are not square, or even rectangular, any more than a number in a sound file is an interval of time. A pixel is a point sample, which can be resampled into square areas if needed.
This is all explained in Alvy Ray Smith's technical memo. Read it and consider yourself enlightened.
Which is highly misleading. What 16 bits per channel really gives you is more dynamic range.
We CRT users are used to going from black (electron gun turned as far down as possible) to white (electron gun turned up as far as possible). "White" for us is a certain point on the black body radiation curve at a certain intensity.
Film users know that this is not the maximum number of photons which are available. In real life, you can always add more. On film, you can usually only add about 20 times more before it's fully exposed, but it's still more, and it's noticeable on specular highlights, such as on chrome or water.
Cineon digital negatives specify 10 bits per channel in logarithmic space, which appears to be sufficient for capturing the high dynamic range. Converting this into linear space (which is more convenient for manipulation) corresponds to about 16 bits, about 12 bits of which (i.e. the range 0-4096) are what we think of as the black to white range. The rest is "headroom" for those times you need the full dynamic range.
Most people, even those in the industry, do. IMO, South Park is the very embodiment of photorealism: The characters look like realistic cartridge paper cutouts.
I was thinking of South Park: Bigger, Longer and Uncut.
Ah, but the original poster won't be doing anything serious to start with, as they'll be spending most of their time learning the tools.
The beauty of Aqsis is not that it is production-ready, but that it gets you started for free while also providing a clean upgrade path. While you're learning how to use Maya, Liquid and RenderMan SL, you can start producing real images and when you're ready, either Aqsis will be suitable for what you want to do (probably not, but you never know), or you can get a copy of something else and just drop it in, taking all the RenderMan(tm) knowledge with you.
First thing, you should be careful with your terminology.
A modeller lets you create models and scenes. A renderer turns these scenes into 2D images. A compositor lets you turn these 2D images into other 2D images, and usually also lets you assemble them into single-file animation formats. Don't expect to do any "real" 3D work without at least one of each.
It's confusing because many modellers have renderers built in. They are usually inadequate for complex jobs. (Though, in fairness, one blockbuster 100% computer animated feature film has been made using Maya's built-in renderer, so it's not exactly useless.) However, thanks to the wonders of Open Source, the modeller is now the only part you have to buy.
Here's what I suggest:
If you find yourself making money with these, you can replace and augment bits if you find them not doing what you want. (For example, replace Aqsis with RDC or PRMan and replace Cinelerra with Shake or After Effects. You can even augment Maya with Houdini or SoftImage if you feel like spending money.)
The key here is to stick with standards so you can drop in replacements into your production line.
Good luck.
I am shocked that someone who calls themselves "be-fan" would be calling microkernels BS. What about BeOS, for heaven's sake?
For every Linus quote there is an equal and opposite Linus quote.
No it is not possible. An aeroplane is private property. Even if the government did not set rules, you would still have no rights apart from those which the owner of the plane allowed you to have. If you don't like it, you are perfectly within your rights to take your car instead.
Repeat until enlightened: Guns don't protect freedom, people protect freedom.
Linus was right at the time, yes. If he were starting Linux today, however, none of those three points would be correct. They're not experimental any more (WinNT before version 4.0, QNX and BeOS are/were all mainstream microkernel OSes), they do not execute notably slower than monolithic kernels (yeah, the Mindcraft survey was rigged, but Linux and NT are still competitive) and (apart from NT) they are no more complex than Linux is today.
On the other hand, "I know I can do it and get it working" would still be a valid argument for him to write a monolithic kernel today, but that's open source for you.
I think you might be confusing yourself.
A monolithic kernel has no fewer layers than a modern microkernel OS. Say you want to write to a file. You make a system call, which goes through the system call interface layer, which then goes to the read() system call implementation, which then goes to the disk subsystem, which then goes to the disk driver.
"But microkernel OSes have to copy stuff around between subsystems", I hear you say. Well that's true under Linux too. At the very least you have to copy the data from user space to kernel space. Compare this with a modern microkernel system where the data is copied straight between your user space and the disk server's user space. Same number of layers, same amount of copying.
Having said, that I agree with you that Mach can't possibly be as fast as, say, Linux, which is why I carefully said this applied to "modern" microkernel systems, such as QNX. So my hopes aren't high for the Hurd, at least in its current incarnation. However, modern microkernel systems which run as fast as modern monolithic kernel systems are here today and they work.
Are you volunteering to do the port of the ~300kloc mentioned while still supporting older versions?
Unfortunately, in the real world, rewriting 80% of the whole system is almost never an option.
The product I am paid to hack on is about 1.5Mloc. While this is bigger than the original poster's system, we've only ported to four platforms (32-bit Solaris, 64-bit Solaris, 32-bit Windows 2000 and IA64 Linux), so I suspect the headache level turns out to be about the same.
When do we get Z39.50 support, then?
Ah, but what is photorealism? What does a non-stylised talking ant look like anyway?
Photorealism is the ability to make it look exactly what you want it to look like, no more, no less.
Not really, but thanks for the pointer. Generally, good sequencers don't make good music typesetters in much the same way that vim or emacs doesn't make a good LaTeX.
Well I don't use any of those, but what I really want is a Linux Finale-alike. (Or, even better, something like Finale which supports multiple movements.) Nobody, as far as I know, is currently working on anything even close to this.
There are several key features of an RTOS which Windows 3.1 does not have.
One is pre-emptability. If an event happens which would cause a higher-priority task to run, it must run within a bounded amount of time.
Another related property is low interrupt delivery latency. If a high-priority interrupt occurs, even if a lower-priority interrupt handler is already running, it should be delivered within a bounded amount of time. This is guaranteed by arranging that nobody disables interrupts for an unbounded amount of time. Indeed, under QNX, interrupt handlers are run with interrupts initially enabled.
Just like how today's procedural languages ain't Fortran, you mean?
No he didn't. He said that OO design is not an indication that software engineering is mature.
Software engineering certainly has a long way to go, but OO has brought it for quite a bit of the distance that it has come in the last ten or so years, particularly in medium-to-large scale heterogenous distributed systems (which would be the sorts of systems that IBM Global Services are particularly interested in). The object has turned out to be almost exactly the Right Thing to model a software component, be it written in the same or a different language, or whether or not it lives on a different machine. We're not even talking about OO languages, necessarily, just OO design.
It depends on the server. Serving streaming media is a fundamentally real-time job, for example. So is ATM switching, not that most servers have an ATM NIC, of course.
The fastest algorithm is always going to be the one which exploits known features of the data. For example, if you know your data is almost sorted, insertion sort will beat heap sort any time, though merge sort will probably do even better, if you can generate initial runs cleverly.
The second fastest algorithm is the one which can recognise common cases and optimise for them, and fall back to a reasonably efficient general algorithm if necessary.
Incidentally, constant factors really matter, especially on modern machines where you have to take into account virtual memory working sets, buffer cache algorithms, cache coherency and so on. An O(N) algorithm with lots of mutex locking (even if there's no contention) may run significantly slower than an O(N log N) algorithm with not as much locking, simply because of the cost of cache synchronisation.
In the non-realtime graphics industry (I used to work in visual effects), they have an equal and opposite law to Moore's Law known as Blinn's Law. It states that the expectation of audiences rises at the same rate as hardware speed increases, making the amount of time taken to compute a frame basically constant.
I no longer work in visual effects. I now hack a Z39.50 server for a living, and the same is true. Machines get faster, but the amount of text that people want to index increases at the same (or greater) speed.
Note that this doesn't negate your point. My desktop machine spends most of its time waiting for me to press the next key (though it does get a lot of protein folding in while it's waiting). However, Moore's Law is rarely a saving grace, especially on the high end.