Why not fight them the way we can as developers. We can always hasten the downfall of SCO as developers. All we need to do is make sure that some key GNU software refuses to compile or run on SCO.
For example, we could make autocon, autogen, automake, binutils, gcc, emacs/xemacs, KDE, Gnome, gdb, gnu tar, cpio, ghostscript, gzip, bzip2, and any other essential GNU tools refuse to compile or run on SCO. SCO would then have to go and spend all of their time patching everything to run on their dead platform. Just make certain that any new GNU software does not work with SCO.
Look at recent versions of GCC. A lot of work has gone into optimizing it and adding support for X86-64. A lot of improvements have gone in to versions 3.2 and many more in the upcoming version 3.3.
While most people don't need over 4GB of RAM, having 64 bits can make life much easier for programmers and provide significant performance advantages. For example, no more relocation will need to occur for shared libraries. Every library could be mapped to a unique address without worry of address clashes so no relocation is necessary (although one of the benefits of the Opteron is better support for relocatable code in 64-bit mode).
Memory mapped files could be the norm. Handling large files becomes much simpler, especially random access.
One easy method of doing what you describe is with some simple microcontrollers. Years ago I worked with Motorola 68HC11s using a serial interface. If you want to control LEDs, you should be able to hook them up directly without requiring relays. You could even adjust brightness by pulsing them quickly in software. Many modern microcontrollers have built-in serial port support as well as embedded flash and RAM.
Of course controlling 8 relays or LEDs with the parallel port is much simpler.
Since the parallel port output is basically just TTL levels, just buffer it through a 74LS244 or something similar and use that to drive the LEDs directly. You can directly control each of the 8 data pins on a parallel port by writing directly to the base I/O port (i.e. port 0x378 is the default for LPT1). It's easiest to use inverting output with TTL driving LEDs.
Something like the following circuit:
D0 ---|>---/\/\/\---|
D0 = parallel port data pin 0
|> is a buffer (i.e. 74LS244) /\/\/\ is resistor
|
(+5) is a 5 volt power source separate from the parallel port.
Make sure that the ground pin of the parallel port is connected to the ground of your circuit. For the 5 volts, a 7805 is a simple solution when using a separate DC power supply.
All of the above listed parts should be available at your local Radio Crap.
When D0 is 0 (low) current will flow from the 5 volt supply, through the LED and resistor and from the buffer to ground. When D0 is 1 (high), no current will flow.
When choosing a resistor, take into account the voltage drop across the LED. Blue LED's typically have a higher voltage drop than red or green. Red LEDs are typically around 0.7 volts whereas blue can be upwards of 3v.
Also make sure that whatever buffer you use can sink the appropriate amount of current. Most LEDs typically will take up to 15-20ma of current. It might also make sense to use an inverter instead of a buffer since the above circuit will cause a LED to light when the data bit is 0. a 74LS04 is a cheap easy-to-use inverter chip that is readily available.
With 20ma of current, choose a resistor based on the voltage.
Use the basic equation, V = I*R, where V is voltage in volts, I is current (in amps) and R is resistance in Ohms.
For example, for a red LED with 20 ma with a 5 volt source use:
R = (5 - 0.7) / 0.020 = 215 ohms. Since resistors come in standard values, choose the next highest value, i.e. 220 Ohms.
For blue, with a 3.6 volt drop you would use
R = (5 - 3.6) / 0.020 = 70 ohms. The closest match is 68 ohms, but it's usually best to error on the side of caution so choose the next larger value.
One thing you do not want to do is use the parallel port to drive LEDs or relays directly as you could possibly damage it. TTL outputs typically are not designed to output much current and are typically better at sinking current than sourcing it.
Note that I'm no expert on this and I'm sure you'll see better solutions listed here.
Cheap extraction of hydrogen should not be difficult. I did a quick google search since I recalled that water dissociates into hydrogen and oxygen at high temperature and came across a 1975 patent for doing this at
http://www.delphion.com/details?pn10=US04053576
. Clearly this should be much more effecient than electrolysis and can be performed via solar energy without photovoltaic cells.
As for storing hydrogen, what about the article on Slashdot a while back about a method of using Borax to store hydrogen in water which is extracted via a catalyst?
A hydrogen based economy is possible, people just need to put some serious effort into looking into all of the methods of extraction and storage to come up with a good inexpensive solution.
The problem is that the initial costs of any solution will be high until it is widely deployed.
The Sun keyboards have the dedicated keys in addition to the function keys. As for the Northgate keyboard, the three fingered salute key is actually a button recessed on the back of the keyboard.
One thing I really like is the Sun keyboards. They have dedicated keys for Undo/Redo, Cut, Copy, Paste, Front (X users will understand this), Open, Help, and a few other keys. Oh, and they keep control where it should be.
Now as a C/C++ programmer what I would *really* like to see is a row of keys for all the non-alphanumeric keys, i.e. !, &, {}, *, >, etc. I know I could just use xmodmap to remap the numeric keys, but I happen to like the numeric keys across the top as well.
My old Northgate keyboard has some cool features, like a full keypad for the cursor keys, not the inverted T, and a dedicated * key. For the Windows users it even has a Ctrl+Alt+Delete button:) It also has the function keys on the side, requiring less stretching to reach.
A good keyboard would also eliminate the CAPS LOCK key to block all the AOL posters.
President William J. Clinton, Vice President Albert Gore Jr., "A Framework For Global Electronic Commerce," Jul. 1997, at http://www.iitf.nist.gov/eleccomm/ecomm.htm, pp. 1-22.
A friend of mine did something similar. At a company I worked at we were trying to qualify a phy chip for a NIC card. One of the things we tested was response to temperature. In one of our labs we had an environmental chamber which was extremely well insulated. Anyway, my friend had the PC running in the chamber with the light on and forgot and left it running over a weekend. On monday morning, anything plastic on the computer was melted, including the CDROM drive. Amazingly enough, the computer was still running. My friend replaced the case and melted CDROM drive and continued to use the system for quite a few more months without any problems. The rest of us wouldn't touch his hardware for some reason.
Re:A little more information
on
Adopt a KDE Geek
·
· Score: 2, Insightful
As someone who regularly compiles KDE from sources for Solaris where I work, it isn't quite this simple. When running the configure script there is an option, --enable-final, which causes the build process to create a single.cpp file that includes all of the other.cpp files in a library. This has two advantages over compiling all of the.cpp files separately. 1. The total compile time is shorter, and 2. the compiler can better optimize the code through inlining.
What is even more time consuming seems to be linking. For some reason libtool takes forever before it starts the actual link process.
Granted, not using --enable-final will speed up the patches, but compiling is still a long and demanding process.
As for debugging, with all the shared libraries, gdb will easily consume 200MB of RAM just to load symbols. God forbid that you link with something like Electric Fence and try and start up a process. A couple of years ago I used this to debug a problem with konsole crashing and starting one konsole session with EF consumed something like 200MB. Loading the resulting core file in GDB took forever since the machine only had 512MB of RAM.
It takes a lot more horsepower to debug and profile code than it takes to run the final code.
I think a fair solution would be to limit the term of a copyright except when the copyrighted material is still being used or distributed by the copyright holder. This would grant Disney full use of Micky Mouse, and would allow people to distribute works that havn't seen the light of day for, say, 25 years. If the copyright holder is the original author then they should be given the option of extending the copyright. If they don't, then it enters the public domain.
This way:
Disney would still maintain the copyrights of their material.
People could legally share music that is no longer distributed and would otherwise rot in some archive vault.
In other words, this would be a use it or lose it copyright. If a company wants to keep the copyright on their material then they are encouraged to use it and make it available. If they don't, then they lose it.
This would allow for books like Tolkein's Lord of the Rings to remain in control of his estate since they continue to use and publish the material, yet a book like "The Bulb Book" by John Weathers which hasn't been published for nearly a century would enter the public domain rather than be lost forever.
This also would give the music industry an incentive to stop pumping out crap that won't see the light of day a decade from now.
For collectors, perhapse the law should state that republishing of expired copyrighted material must state so, such that collectors can still know what is original or modern copies.
Because the Japanese standard was ANALOG and was a huge bandwidth hog and as far as I know been abandoned. From what I understand they are replacing it with basically the US standard.
The report covers Windows, but I want to know about the effect on Linux. A couple of years ago I ran Seti@home on some of the Solaris boxes where I worked. Even though it was nice -19, it had a very noticable impact on system performance. My solution was a script that monitored the system load and killed the client whenever the server was busy doing real work.
In Windows, I think there are scheduling classes such that a low priority idle task will not receive any cycles if a normal priority task needs to run.
When investigating various network processors, I see that all of the vendors I have looked at supply drivers for embedded Linux. In fact, Linux appears to have better support than any other operating system (including VxWorks and QNX). GPL is not an issue for them, even though the drivers are highly proprietary. Why not ask an embedded Linux vendor like Monte Vista (Hard Hat Linux) and see what response you get?
What I want to see is how it handles memory intensive benchmarks. I think this may be where it will shine, with the DDR interface built directly into the processor, thus eliminating latency and bottlenecks imposed by the north bridge.
The other big advantage most people seem to forget is the amount of memory addressing capability. Where I work, we have racks of Linux X86 servers with 6GB of memory each. While there are hacks to go beyond 4GB, it gets kind of ugly. With Opteron, addressing 6GB or more of memory is not a problem.
Also, with their Hypertransport bus and supporting multiple processors, the amount of memory scales with the number of CPUs.
With my Replay I can set options for a show to start x minutes early and/or stop y minutes after so you can add padding fairly easily, but it has to be configured when each show is configured for recording.
One problem, though, is that the Replay only handles NTSC.
10 years ago myself and a few friends did just that. We built a couple of Ramsey stereo FM kits and just started broadcasting music. The range was short (around 1/3 mile) but a few of the dorms could pick up the radio without any problems. The Ramsey kit can be had for around $20-30.
I have an Epson Stylus Color 800 printer which I had used with OS/2 and Windows with few problems. I have it connected to a network print server so I can easily share it on my LAN. SuSE Linux, however, has been nothing but trouble. When I finally got the margins working right, it randomly inserts horizontal lines in the output. It isn't the printer cable since it is connected to a print server.
I finally got fed up and bought a used HP Laserjet 4M/Plus fully loaded with memory, Postscript, and an Ethernet port and havn't looked back since. The output is great and I have had zero problems with it.
Hopefully it will compile without any major problems, unlike releases 3.0 and 3.1. I have yet to successfully compile GCC 3.1 on Solaris running on an Ultrasparc. I had few problems with 2.95.3.
When I was designing support for discarding packets in a BRAS (Broadband Remote Access Server), I put in support to prioritize control packets (i.e. tcp ACK over data packets to try and make this a lot better. A BRAS is a box that sits at the other end of a DSL modem and terminates PPP and PPPoE sessions (and more). This would only affect traffic going to the end user since the upstream traffic is usually shaped in the modem. I put this in specifically to deal with the problem you describe. I ran into the same problem when @Home reduced the upstream bandwidth to 128Kbps from 1Mbps. I did some shaping on the software running on my computer which helped a lot, but most users don't have that flexibility.
The box I'm working on supports tens of thousands of simultaneous DSL users and can shape and buffer each user's traffic independently, going so far as being able to shape individual traffic flows to and from a user. It's also designed so that a user can change the amount of bandwidth they want on the fly and letting the ISP choose how to charge for this. This also allows for things like downloading video on demand, where the pipe from a video server to the subscriber can guarantee bandwidth for that flow.
As for shaping traffic in Windows? I havn't a clue. I don't do Windows.
A few years ago I purchased 1000' of CAT 5e rated at 350MHz for around $50 to install in my house. I guess the cable is at least as good as CAT6. It's a real pain in the butt for crimping connectors, though, since each twisted pair is bonded together (like a 2 conductor ribbon cable) and must be separated.
What I would like to see is a good programmer's keyboard designed for C, C++, and Java programming.
The current QUERTY (and DVORAK for that matter) layout requires too much use of the pinky finger (the weakest finger). I feel some of the keys would benefit from being moved elsewhere, for example the following:
SHIFT and ENTER.
I use shift so often I wish it were located in the middle of the space bar where I could hit it with my thumb.
I also wish common symbols used in programming didn't require shift all the time (i.e. *, +, ", {, }, &, !, %, (, ), and # (for shell scripts/Perl)}. My home keyboard is an improvement (a Northgate OmniKey/Plus) since it has a dedicated "*" key and the function keys at the left.
Also, for X I really like the added keys Sun has (like front, cut, copy, paste, undo, redo, etc.)
This sounds like my experience with SuSE Linux 8.0 and KDE 3.0. If I click on a.rpm file in konqueror, krpm pops up and allows me to install the new software. Before allowing the install, it requests the root password. In this way, I do not need to log in as root to install new software.
Of course something along the lines of InstallShield would make installing new software easier and more flexible.
A few months ago I attended a SMPTE (Society of Motion Picture and Television Engineers) meeting held at Pixar. The meeting was held in their screening room. The screening room is equipped with both a traditional 35MM film projector anda DLP projector with a resolution of 1280x1024.
For the first part of the demonstration they showed a clip from Monsters Inc. split screen, with the left half the digital projector and the right half the film projector.
It became immediately apparent the advantages of the DLP projector over the film projector.
With the side-by-side showing, the jitter of the film became immediately visible. The detail of the DLP image was better. Also, the DLP is capable of much better contrast than film.
Now the film that was shown was of higher quality than that shown in the theaters, and the projector was also better than that in most theaters (and is also better maintained).
This isn't to say that there were no DLP artifacts. There were some, but they were not very noticable compared to the artifacts that usually appear in film. The film shown had no dirt or scratches, but in the typical theater this is not the case.
Unlike film, there's nothing to wear out in the media.
As far as the projector lasting a long time, the only real problem I hear of is that the light bulb must be periodically replaced (which cost around $100). The DLP should last a long time.
Slashdot Mirror
For example, we could make autocon, autogen, automake, binutils, gcc, emacs/xemacs, KDE, Gnome, gdb, gnu tar, cpio, ghostscript, gzip, bzip2, and any other essential GNU tools refuse to compile or run on SCO. SCO would then have to go and spend all of their time patching everything to run on their dead platform. Just make certain that any new GNU software does not work with SCO.
That will get their attention.
Look at recent versions of GCC. A lot of work has gone into optimizing it and adding support for X86-64. A lot of improvements have gone in to versions 3.2 and many more in the upcoming version 3.3.
While most people don't need over 4GB of RAM, having 64 bits can make life much easier for programmers and provide significant performance advantages. For example, no more relocation will need to occur for shared libraries. Every library could be mapped to a unique address without worry of address clashes so no relocation is necessary (although one of the benefits of the Opteron is better support for relocatable code in 64-bit mode).
Memory mapped files could be the norm. Handling large files becomes much simpler, especially random access.
-Aaron
Of course controlling 8 relays or LEDs with the parallel port is much simpler.
Since the parallel port output is basically just TTL levels, just buffer it through a 74LS244 or something similar and use that to drive the LEDs directly. You can directly control each of the 8 data pins on a parallel port by writing directly to the base I/O port (i.e. port 0x378 is the default for LPT1). It's easiest to use inverting output with TTL driving LEDs.
Something like the following circuit:
D0 ---|>---/\/\/\---| D0 = parallel port data pin 0
/\/\/\ is resistor
|> is a buffer (i.e. 74LS244)
| (+5) is a 5 volt power source separate from the parallel port.
Make sure that the ground pin of the parallel port is connected to the ground of your circuit. For the 5 volts, a 7805 is a simple solution when using a separate DC power supply.
All of the above listed parts should be available at your local Radio Crap.
When D0 is 0 (low) current will flow from the 5 volt supply, through the LED and resistor and from the buffer to ground. When D0 is 1 (high), no current will flow.
When choosing a resistor, take into account the voltage drop across the LED. Blue LED's typically have a higher voltage drop than red or green. Red LEDs are typically around 0.7 volts whereas blue can be upwards of 3v.
Also make sure that whatever buffer you use can sink the appropriate amount of current. Most LEDs typically will take up to 15-20ma of current. It might also make sense to use an inverter instead of a buffer since the above circuit will cause a LED to light when the data bit is 0. a 74LS04 is a cheap easy-to-use inverter chip that is readily available.
With 20ma of current, choose a resistor based on the voltage.
Use the basic equation, V = I*R, where V is voltage in volts, I is current (in amps) and R is resistance in Ohms.
For example, for a red LED with 20 ma with a 5 volt source use:
R = (5 - 0.7) / 0.020 = 215 ohms. Since resistors come in standard values, choose the next highest value, i.e. 220 Ohms.
For blue, with a 3.6 volt drop you would use
R = (5 - 3.6) / 0.020 = 70 ohms. The closest match is 68 ohms, but it's usually best to error on the side of caution so choose the next larger value.
One thing you do not want to do is use the parallel port to drive LEDs or relays directly as you could possibly damage it. TTL outputs typically are not designed to output much current and are typically better at sinking current than sourcing it.
Note that I'm no expert on this and I'm sure you'll see better solutions listed here.
-Aaron
As for storing hydrogen, what about the article on Slashdot a while back about a method of using Borax to store hydrogen in water which is extracted via a catalyst?
A hydrogen based economy is possible, people just need to put some serious effort into looking into all of the methods of extraction and storage to come up with a good inexpensive solution.
The problem is that the initial costs of any solution will be high until it is widely deployed.
-Aaron
The Sun keyboards have the dedicated keys in addition to the function keys. As for the Northgate keyboard, the three fingered salute key is actually a button recessed on the back of the keyboard.
One thing I really like is the Sun keyboards. They have dedicated keys for Undo/Redo, Cut, Copy, Paste, Front (X users will understand this), Open, Help, and a few other keys. Oh, and they keep control where it should be.
:) It also has the function keys on the side, requiring less stretching to reach.
Now as a C/C++ programmer what I would *really* like to see is a row of keys for all the non-alphanumeric keys, i.e. !, &, {}, *, >, etc. I know I could just use xmodmap to remap the numeric keys, but I happen to like the numeric keys across the top as well.
My old Northgate keyboard has some cool features, like a full keypad for the cursor keys, not the inverted T, and a dedicated * key. For the Windows users it even has a Ctrl+Alt+Delete button
A good keyboard would also eliminate the CAPS LOCK key to block all the AOL posters.
-Aaron
Al Gore is actually referenced in the patent.
In patent 6,253,203:
Other References
President William J. Clinton, Vice President Albert Gore Jr., "A Framework For Global Electronic Commerce," Jul. 1997, at http://www.iitf.nist.gov/eleccomm/ecomm.htm, pp. 1-22.
A friend of mine did something similar. At a company I worked at we were trying to qualify a phy chip for a NIC card. One of the things we tested was response to temperature. In one of our labs we had an environmental chamber which was extremely well insulated. Anyway, my friend had the PC running in the chamber with the light on and forgot and left it running over a weekend. On monday morning, anything plastic on the computer was melted, including the CDROM drive. Amazingly enough, the computer was still running. My friend replaced the case and melted CDROM drive and continued to use the system for quite a few more months without any problems. The rest of us wouldn't touch his hardware for some reason.
As someone who regularly compiles KDE from sources for Solaris where I work, it isn't quite this simple. When running the configure script there is an option, --enable-final, which causes the build process to create a single .cpp file that includes all of the other .cpp files in a library. This has two advantages over compiling all of the .cpp files separately. 1. The total compile time is shorter, and 2. the compiler can better optimize the code through inlining.
What is even more time consuming seems to be linking. For some reason libtool takes forever before it starts the actual link process.
Granted, not using --enable-final will speed up the patches, but compiling is still a long and demanding process.
As for debugging, with all the shared libraries, gdb will easily consume 200MB of RAM just to load symbols. God forbid that you link with something like Electric Fence and try and start up a process. A couple of years ago I used this to debug a problem with konsole crashing and starting one konsole session with EF consumed something like 200MB. Loading the resulting core file in GDB took forever since the machine only had 512MB of RAM.
It takes a lot more horsepower to debug and profile code than it takes to run the final code.
-Aaron
I think a fair solution would be to limit the term of a copyright except when the copyrighted material is still being used or distributed by the copyright holder. This would grant Disney full use of Micky Mouse, and would allow people to distribute works that havn't seen the light of day for, say, 25 years. If the copyright holder is the original author then they should be given the option of extending the copyright. If they don't, then it enters the public domain.
This way:
Disney would still maintain the copyrights of their material.
People could legally share music that is no longer distributed and would otherwise rot in some archive vault.
In other words, this would be a use it or lose it copyright. If a company wants to keep the copyright on their material then they are encouraged to use it and make it available. If they don't, then they lose it.
This would allow for books like Tolkein's Lord of the Rings to remain in control of his estate since they continue to use and publish the material, yet a book like "The Bulb Book" by John Weathers which hasn't been published for nearly a century would enter the public domain rather than be lost forever.
This also would give the music industry an incentive to stop pumping out crap that won't see the light of day a decade from now.
For collectors, perhapse the law should state that republishing of expired copyrighted material must state so, such that collectors can still know what is original or modern copies.
> Why didn't american's just borrow the standard.
Because the Japanese standard was ANALOG and was a huge bandwidth hog and as far as I know been abandoned. From what I understand they are replacing it with basically the US standard.
The report covers Windows, but I want to know about the effect on Linux. A couple of years ago I ran Seti@home on some of the Solaris boxes where I worked. Even though it was nice -19, it had a very noticable impact on system performance. My solution was a script that monitored the system load and killed the client whenever the server was busy doing real work.
In Windows, I think there are scheduling classes such that a low priority idle task will not receive any cycles if a normal priority task needs to run.
-Aaron
When investigating various network processors, I see that all of the vendors I have looked at supply drivers for embedded Linux. In fact, Linux appears to have better support than any other operating system (including VxWorks and QNX). GPL is not an issue for them, even though the drivers are highly proprietary. Why not ask an embedded Linux vendor like Monte Vista (Hard Hat Linux) and see what response you get?
-Aaron
What I want to see is how it handles memory intensive benchmarks. I think this may be where it will shine, with the DDR interface built directly into the processor, thus eliminating latency and bottlenecks imposed by the north bridge.
The other big advantage most people seem to forget is the amount of memory addressing capability. Where I work, we have racks of Linux X86 servers with 6GB of memory each. While there are hacks to go beyond 4GB, it gets kind of ugly. With Opteron, addressing 6GB or more of memory is not a problem.
Also, with their Hypertransport bus and supporting multiple processors, the amount of memory scales with the number of CPUs.
-Aaron
With my Replay I can set options for a show to start x minutes early and/or stop y minutes after so you can add padding fairly easily, but it has to be configured when each show is configured for recording.
One problem, though, is that the Replay only handles NTSC.
10 years ago myself and a few friends did just that. We built a couple of Ramsey stereo FM kits and just started broadcasting music. The range was short (around 1/3 mile) but a few of the dorms could pick up the radio without any problems. The Ramsey kit can be had for around $20-30.
I have an Epson Stylus Color 800 printer which I had used with OS/2 and Windows with few problems. I have it connected to a network print server so I can easily share it on my LAN. SuSE Linux, however, has been nothing but trouble. When I finally got the margins working right, it randomly inserts horizontal lines in the output. It isn't the printer cable since it is connected to a print server.
I finally got fed up and bought a used HP Laserjet 4M/Plus fully loaded with memory, Postscript, and an Ethernet port and havn't looked back since. The output is great and I have had zero problems with it.
Hopefully it will compile without any major problems, unlike releases 3.0 and 3.1. I have yet to successfully compile GCC 3.1 on Solaris running on an Ultrasparc. I had few problems with 2.95.3.
-Aaron
When I was designing support for discarding packets in a BRAS (Broadband Remote Access Server), I put in support to prioritize control packets (i.e. tcp ACK over data packets to try and make this a lot better. A BRAS is a box that sits at the other end of a DSL modem and terminates PPP and PPPoE sessions (and more). This would only affect traffic going to the end user since the upstream traffic is usually shaped in the modem. I put this in specifically to deal with the problem you describe. I ran into the same problem when @Home reduced the upstream bandwidth to 128Kbps from 1Mbps. I did some shaping on the software running on my computer which helped a lot, but most users don't have that flexibility.
The box I'm working on supports tens of thousands of simultaneous DSL users and can shape and buffer each user's traffic independently, going so far as being able to shape individual traffic flows to and from a user. It's also designed so that a user can change the amount of bandwidth they want on the fly and letting the ISP choose how to charge for this. This also allows for things like downloading video on demand, where the pipe from a video server to the subscriber can guarantee bandwidth for that flow.
As for shaping traffic in Windows? I havn't a clue. I don't do Windows.
A few years ago I purchased 1000' of CAT 5e rated at 350MHz for around $50 to install in my house. I guess the cable is at least as good as CAT6. It's a real pain in the butt for crimping connectors, though, since each twisted pair is bonded together (like a 2 conductor ribbon cable) and must be separated.
-Aaron
What I would like to see is a good programmer's keyboard designed for C, C++, and Java programming.
The current QUERTY (and DVORAK for that matter) layout requires too much use of the pinky finger (the weakest finger). I feel some of the keys would benefit from being moved elsewhere, for example the following:
SHIFT and ENTER.
I use shift so often I wish it were located in the middle of the space bar where I could hit it with my thumb.
I also wish common symbols used in programming didn't require shift all the time (i.e. *, +, ", {, }, &, !, %, (, ), and # (for shell scripts/Perl)}. My home keyboard is an improvement (a Northgate OmniKey/Plus) since it has a dedicated "*" key and the function keys at the left.
Also, for X I really like the added keys Sun has (like front, cut, copy, paste, undo, redo, etc.)
-Aaron
This sounds like my experience with SuSE Linux 8.0 and KDE 3.0. If I click on a .rpm file in konqueror, krpm pops up and allows me to install the new software. Before allowing the install, it requests the root password. In this way, I do not need to log in as root to install new software.
Of course something along the lines of InstallShield would make installing new software easier and more flexible.
-Aaron
The Pixar screening room was a good sized theater that I'd guess could easily seat a couple hundred people.
A few months ago I attended a SMPTE (Society of Motion Picture and Television Engineers) meeting held at Pixar. The meeting was held in their screening room. The screening room is equipped with both a traditional 35MM film projector anda DLP projector with a resolution of 1280x1024.
For the first part of the demonstration they showed a clip from Monsters Inc. split screen, with the left half the digital projector and the right half the film projector.
It became immediately apparent the advantages of the DLP projector over the film projector.
With the side-by-side showing, the jitter of the film became immediately visible. The detail of the DLP image was better. Also, the DLP is capable of much better contrast than film.
Now the film that was shown was of higher quality than that shown in the theaters, and the projector was also better than that in most theaters (and is also better maintained).
This isn't to say that there were no DLP artifacts. There were some, but they were not very noticable compared to the artifacts that usually appear in film. The film shown had no dirt or scratches, but in the typical theater this is not the case.
Unlike film, there's nothing to wear out in the media.
As far as the projector lasting a long time, the only real problem I hear of is that the light bulb must be periodically replaced (which cost around $100). The DLP should last a long time.