When performing calculations that can take hours or days even, an increase in performance of even 10% can result in significant time/money savings.
I was under the impression that an overclocked CPU usually ran rather flaky with spurious crashes and lockups. Do you really dare to run calculations that take days to complete on an overclocked processor?
Is the patent-owner at all involved, is he even still at Cornell?
Since the patent is owned by the Cornell university, they are the ones who should defend it. In most cases, copyrights and patents are owned by the employer and not the employee.
On the other hand, if they win the students might benefit from it with lower fees/more equipment.
Running binaries as root
on
Linux Virus Alert
·
· Score: 5, Informative
Ya, I run lots of unknown binaries while logged in as root, it's my favorite activity.
I realize of course that you are joking, but I do believe that a lot of users run a lot of untrusted stuff as root. How many times have you run "make install" as root? I certainly have done it a few times for software packages that I downloaded from untrusted sources and without having read through the entire Makefile first. Who knows what kind of programs that I might unwillingly have run as root?
RPMs or other packages that are downloaded from more or less untrusted locations without encryption signatures might very well run a few evil scripts during the installation process (which, of course, is done as root).
To be really sure, one should always install new programs in a chrooted jail; the software should be installed in a totally new branch of the filesystem tree and the installation process should not be able to read of write to other parts the filesystem.
2005: I get to use Microsoft at work, Linux on my web server, Simbian on my phone and some other random Sony OS on my television... joy.
Most people unknowingly use a multitude of operating systems in their daily lives, even today. They use OSE on their cellphone, RTXC on their microwave oven, pSOS in their car's control system, RTEMS in their stereo system, vxWorks in their dishwasher and perhaps even Linux in their VCR. Almost every device we use today is equipped with embedded small computers and they all run different operating systems.
We shouldn't be striving for a "standard" OS in all those appliences. (Who would want to run Windows in their embedded systems anyway? Yes, Microsoft would probably succeed in making Windows the standard OS in such a case...) We should be setting standards for exchanging data between those systems instead.
TCP/IP is a good carrier of the information exchange - the global Internet has proven that. But service discovery, naming and security are issues that needs to be delt with. Hopefully, this will be developed out in the open just like the Internet protocols once were developed and not beind closed doors, patents and intelectual property lock-ins.
For those of you who haven't read enough computer science to know what O(1) means, here is a short explanation.
The Big O-notation is a way to describe how the (asymptotic) execution time of an algorithm depends on the inputs to the algorithm. For instance, an algorithm that loops over n values is said to have the asymptotic execution time O(n) - it is proportional to the number of times the loop is executed.
Similarly, an algorithm that runs in constant time, i.e., that takes equally long to execute for 10 values and for 1000000 values, is said to be O(1). The execution time is proportional to 1.
For the Linux scheduler, switching processes is O(p), where p is the number of currently running processes. This new scheduler switches processes in O(1) time.
This means that even though the old scheduler might be fast for low numbers of running processes, it will take longer and longer timer to switch processes when the number of active processes grow. The new scheduler will switch processes just as fast for 2 processes or for 200 processes. Even though the new scheduler might be slower in when there are few processes, it will be faster when the number of running processes increase.
FFTW, "the fastest Fast Fourier Transform in the West", is an implementation of the DFT (Discrete Fourier Transform) that was developed as part of a research project at MIT. FFTW is released under the GPL, and Section 1.4 in their FAQ one can read that they are using the system you describe:
We could instead have released FFTW under the LGPL, or even disallowed non-Free usage. Suffice it to say, however, that MIT owns the copyright to FFTW and they only let us GPL it because we convinced them that it would neither affect their licensing revenue nor irritate existing licensees.
Hiding research results/prototypes is bad science
on
Public Money, Private Code
·
· Score: 3, Insightful
Science depends on the ability to duplicate research results. It must be possible for independant researchers to duplicate and verify the results of other scientists, otherwise the results might just as well have been made up. If research prototypes in the form of source code are being hidden behind intelectual property laws and proprietary licensing, science will stop moving forward.
If the software produced is the result of the research, then hiding the source code is even more disasterous. Hiding research results it probably the best way to totally cripple science as we know it.
Research must be conducted under the scrutiny of the public eye to be truly useful.
If you think this is cool, you might want to check out this. It is a Commodore 64 that is running as a web server, and has been up 24/7 since november 2001. It is connected to the Internet via a 38400 bps SLIP link so it is quite slow.
For those of you who doesn't remember the Commodore 64, it was a very popular home computer in the 80's and early 90's. It has 64k RAM and an 8-bit 1 MHz 6502 CPU.
The C64 web server is running the small uIP TCP/IP stack that is less than 4k large and uses only a few hundred bytes of dynamic RAM. Since it is written in C, it has been ported to numerous other systems such as the 8-bit Ataris and a number of embedded processors such as the Hitachi H8S.
2) Game Shark (according to the article) does not use the cheats made by the companies, although, I suspect that if they are reverse engineering it, they could view the cheats. But what they do is write/edit the RAM (memory) at given moments to enhance a feature. Let's say that in memory location 255, the game Mortal Kombat stores the maximum health of player 1. What the GameShark does is, instead of letting the game store 100% there, it writes in 500% (let's say) which gives you more health. Or another way would be to store -1 or something that the program doesn't expect.
Does anyone remember the good old C64 games, where you cheated by resetting the machine, issuing a few POKE commands and restart the game using a SYS command? That utilized the exact same tecnique - POKE stored a value in RAM and SYS started executing the game.
Usually, however, these POKEs didn't rewrite RAM locations where the number of lives were stored. Instead, it replaced the actual machine code that decremented the life counter. So instead of doing:
dec $5463
The game now did:
nop
nop
nop
Which uses the same number of bytes of RAM.
There even existed hardware devices (called cartridges) that enabled you to automatically scan the memory for the locations of life counters and such. Once the life counter was found, the game code was patched in the way outlined above.
The obvious question is "what classifies as a VPN?" A VPN is a Virtual Private Network which usually is constructed using a secure IP layer such as IPsec. While it is easy to scan for IPsec usage (it has it's own protocol number - even as TCP and UDP has), it is much harder to scan for other types of VPN solutions.
Even encrypted HTTP, HTTPS, can be used to build a VPN-similar type of thing (think "VNC"). Since HTTPS is used to encrypt on-line banking traffic, e-commerce sites and such, they cannot just stop everyone from using HTTPS.
Furthermore, since the data (by definition) is encrypted, it is impossible to peek at the data to determine if a data stream is "a VPN" or just some other HTTPS transfer.
The conlusion is that they will have huge problems trying to enforce this.
The whole Internet depends on protocols that have built-in congestion responses that mimic those of TCP. Protocols that don't either starve TCP flows, or are starved by them. Protocols with no real congestion response at all rapidly destabilize Internet links by consuming all available resources. Digital Fountain originally targeted multicast media transfer. Congestion avoidance in multicast schemes is still an open research question. Does this protocol really scale?
Yes, their protocol uses TCP-friendly congestion control - read about it in their SIGCOMM paper.
They achieve TCP-friendly congestion control by using layered multicasts. Data is sent on multiple multicast groups; a high-bandwidth receiver joins more groups than a low-bandwidth one. The transmission rates and interarrival times between so-called syncronization points can be set up in ways that makes the transmission TCP-friendly.
For those of you who don't know it, this stuff is based on some very serious research performed at the University of California in Berkeley (yes, the same place that spouted the famous BSD system) together with Digital Systems research center in Palo Alto. It was published at one of most well-renowned networking conferences, SIGCOMM, in 1998. Here
is a link which provides not only the paper, but also slides from the presentation.
The digital fountain approach is not a way to transmit information without transmitting it as the brurb suggests. Rather, it is an ingenious way of using forward error correction (so-called erasure codes) and broadcast (or multicast for that matter) to distribute data to a large amount of receivers.
In short, each data packet includes enough reduntant information to allow a receiver that has lost a few packets to get back in sync after receiving a number of the broadcasted packets.
This way, the sender does not need to do any retransmissions; losses are repaired by the new packets that is sent out.
One place where this kind of technique could be used would be when a new, large, software package such as KDE, GNOME, or the Linux kernel, is to be distributed to a large number of receivers. The sender would just send data in a fixed rate and the receivers would just have to "tune in" to the data stream. After some time, the whole package is received. No more spikes in bandwidth consumption and no more slashdot effects.
My thoughts exactly - it runs fast, lean and most amazing of all, switches into and out of graphics mode (direct hardware hitting, even!) without causing NT to gripe! I am still trying to figure that out (hey, l33t ASM coder I am not).
Actually, switching in and out of graphics mode is the least of problems with writing stuff such as this. Switching to 320x200 mode is done by those two lines of code:
Is it really fair to say that they are profiting from free software? Their plugin exists because people want to be able to run proprietary software in the form of web browser plugins. People wouldn't buy the CrossOver plugin if all Windows based plugins were free software - in that case, people could just download the source for the Windows plugins and compile them for themselves.
I think it is more fair to say that they are making their profit from the proprietary Windows based plugins that their software is able to run. Eventhough these plugins are free (as in beer).
All ISPs which I am familiar with say the same about Linux, *BSD, or any other kind of operating system which isn't Windows 95/98 or MacOS. It just means that they can say "sorry, we don't support your system" whenever there is a problem and you run an "exotic" system even when the problem happens to be within their system.
I tend not to reveal that I run a non-supported system when I report problems...
If you think that 64k is small, check out the amazing Omnicent demo. This is a (non-playable) clone of the good old 3D game Descent, but coded in 4096 bytes, including wall textures and music! Furthermore, it doesn't require any extra hardware or software; it runs under MS-DOS and draws directly to the VGA card.
Tiny C64 TCP/IP stack and web server
on
Tiny Apps
·
· Score: 1
Take a look at http://c64.cc65.org/. It is a good old C64 working as a web server. It runs the uIP TCP/IP stack, which is written in C and is really tiny; the code is around 4k large and it uses some 200 bytes of RAM.
I couldn't agree more. Testing is incredibly important for software projects and automated tests makes sure that certain test are not forgotten.
GCC has a test suite: http://gcc.gnu.org/testresults/ and uses the test suite as a formal release criterion. The GCC team also uses those tests as benchmarks for the compiler.
Different types of niche operating systems
on
Niche Operating Systems
·
· Score: 5, Insightful
In my (somewhat limited) experience with niche operating systems for PCs, they can roughly be divided into two categories:
"Toy" systems that are written by a few hackers "just because they can". Those are typically written in (x86) assembler and even eary versions can produce a nice looking GUI. (Note that "toy" systems can very rigid and functional, despite their name.)
"Research" systems that are written by researchers to prove a point. The rarely have a GUI (unless the research involve real-time graphics as for Nemesis).
Both kinds are extremely hard to install, only run on a very carefully selected set of hardware, and don't really gain much appreciation other than from a very small group of followers. Followers from both groups often look down on eachother.
Lately, the operating systems research has come to a slowdown, but the operating system hackers (that produce the "toy" systems) are gaining more and more momentum. The latter can most likely be contributed to the success of Linux. Can the former be explained by that operating systems now is a fully explored area?
IMHO, what's needed is a GUI that'll do for X what RISC architectures did for processors. Produce a MUCH simpler underlying architecture, using layers to provide more and more complex functionality.
But isn't this exactly what X is? The X server is just a very dumb program that only knows how to draw lines, boxes, circles, and fonts. Everything else (i.e., the complexity) is layered on top of this through toolkits and window managers.
A GNOME program uses the simple GTK toolkit to provide the GUI. GTK uses Xlib which uses X. The complexity is layered.
Furthermore, neither the application nor the toolkit needs to worry about how the window is managed; this is taken care of by the window manager program. The window manager interacts with the user and moves, resizes, and iconifies windows. Layered complexity once again.
In fact, this has nothing to do with the GPL. This is how the copyright laws work; you cannot distribute a program that you don't hold the copyright to, unless the copyright holder has granted you permission to redistribute the program.
The GPL gives everyone the permission to redistribute the program, provided that they follow the requirements stated in the GPL. Those include, among other things, that it must be possible to obtain the source code for the entire program, including modifications.
So, this case does not really have anything to do with the GPL. It is a standard case where copyright has been breached.
Slashdot Mirror
On the other hand, if they win the students might benefit from it with lower fees/more equipment.
RPMs or other packages that are downloaded from more or less untrusted locations without encryption signatures might very well run a few evil scripts during the installation process (which, of course, is done as root).
To be really sure, one should always install new programs in a chrooted jail; the software should be installed in a totally new branch of the filesystem tree and the installation process should not be able to read of write to other parts the filesystem.
We shouldn't be striving for a "standard" OS in all those appliences. (Who would want to run Windows in their embedded systems anyway? Yes, Microsoft would probably succeed in making Windows the standard OS in such a case...) We should be setting standards for exchanging data between those systems instead.
TCP/IP is a good carrier of the information exchange - the global Internet has proven that. But service discovery, naming and security are issues that needs to be delt with. Hopefully, this will be developed out in the open just like the Internet protocols once were developed and not beind closed doors, patents and intelectual property lock-ins.
For those of you who haven't read enough computer science to know what O(1) means, here is a short explanation.
The Big O-notation is a way to describe how the (asymptotic) execution time of an algorithm depends on the inputs to the algorithm. For instance, an algorithm that loops over n values is said to have the asymptotic execution time O(n) - it is proportional to the number of times the loop is executed.
Similarly, an algorithm that runs in constant time, i.e., that takes equally long to execute for 10 values and for 1000000 values, is said to be O(1). The execution time is proportional to 1.
For the Linux scheduler, switching processes is O(p), where p is the number of currently running processes. This new scheduler switches processes in O(1) time.
This means that even though the old scheduler might be fast for low numbers of running processes, it will take longer and longer timer to switch processes when the number of active processes grow. The new scheduler will switch processes just as fast for 2 processes or for 200 processes. Even though the new scheduler might be slower in when there are few processes, it will be faster when the number of running processes increase.
I think Microsoft intended that it should be pronounced "C sharp", just as the musical term.
Science depends on the ability to duplicate research results. It must be possible for independant researchers to duplicate and verify the results of other scientists, otherwise the results might just as well have been made up. If research prototypes in the form of source code are being hidden behind intelectual property laws and proprietary licensing, science will stop moving forward.
If the software produced is the result of the research, then hiding the source code is even more disasterous. Hiding research results it probably the best way to totally cripple science as we know it.
Research must be conducted under the scrutiny of the public eye to be truly useful.
If you think this is cool, you might want to check out this. It is a Commodore 64 that is running as a web server, and has been up 24/7 since november 2001. It is connected to the Internet via a 38400 bps SLIP link so it is quite slow.
For those of you who doesn't remember the Commodore 64, it was a very popular home computer in the 80's and early 90's. It has 64k RAM and an 8-bit 1 MHz 6502 CPU.
The C64 web server is running the small uIP TCP/IP stack that is less than 4k large and uses only a few hundred bytes of dynamic RAM. Since it is written in C, it has been ported to numerous other systems such as the 8-bit Ataris and a number of embedded processors such as the Hitachi H8S.
2) Game Shark (according to the article) does not use the cheats made by the companies, although, I suspect that if they are reverse engineering it, they could view the cheats. But what they do is write/edit the RAM (memory) at given moments to enhance a feature. Let's say that in memory location 255, the game Mortal Kombat stores the maximum health of player 1. What the GameShark does is, instead of letting the game store 100% there, it writes in 500% (let's say) which gives you more health. Or another way would be to store -1 or something that the program doesn't expect.
Does anyone remember the good old C64 games, where you cheated by resetting the machine, issuing a few POKE commands and restart the game using a SYS command? That utilized the exact same tecnique - POKE stored a value in RAM and SYS started executing the game.
Usually, however, these POKEs didn't rewrite RAM locations where the number of lives were stored. Instead, it replaced the actual machine code that decremented the life counter. So instead of doing:
dec $5463
The game now did:
nop
nop
nop
Which uses the same number of bytes of RAM.
There even existed hardware devices (called cartridges) that enabled you to automatically scan the memory for the locations of life counters and such. Once the life counter was found, the game code was patched in the way outlined above.
Ahhh, those were the days!
The obvious question is "what classifies as a VPN?" A VPN is a Virtual Private Network which usually is constructed using a secure IP layer such as IPsec. While it is easy to scan for IPsec usage (it has it's own protocol number - even as TCP and UDP has), it is much harder to scan for other types of VPN solutions.
Even encrypted HTTP, HTTPS, can be used to build a VPN-similar type of thing (think "VNC"). Since HTTPS is used to encrypt on-line banking traffic, e-commerce sites and such, they cannot just stop everyone from using HTTPS.
Furthermore, since the data (by definition) is encrypted, it is impossible to peek at the data to determine if a data stream is "a VPN" or just some other HTTPS transfer.
The conlusion is that they will have huge problems trying to enforce this.
The whole Internet depends on protocols that have built-in congestion responses that mimic those of TCP. Protocols that don't either starve TCP flows, or are starved by them. Protocols with no real congestion response at all rapidly destabilize Internet links by consuming all available resources. Digital Fountain originally targeted multicast media transfer. Congestion avoidance in multicast schemes is still an open research question. Does this protocol really scale?
Yes, their protocol uses TCP-friendly congestion control - read about it in their SIGCOMM paper.
They achieve TCP-friendly congestion control by using layered multicasts. Data is sent on multiple multicast groups; a high-bandwidth receiver joins more groups than a low-bandwidth one. The transmission rates and interarrival times between so-called syncronization points can be set up in ways that makes the transmission TCP-friendly.
For those of you who don't know it, this stuff is based on some very serious research performed at the University of California in Berkeley (yes, the same place that spouted the famous BSD system) together with Digital Systems research center in Palo Alto. It was published at one of most well-renowned networking conferences, SIGCOMM, in 1998. Here is a link which provides not only the paper, but also slides from the presentation.
The digital fountain approach is not a way to transmit information without transmitting it as the brurb suggests. Rather, it is an ingenious way of using forward error correction (so-called erasure codes) and broadcast (or multicast for that matter) to distribute data to a large amount of receivers.
In short, each data packet includes enough reduntant information to allow a receiver that has lost a few packets to get back in sync after receiving a number of the broadcasted packets. This way, the sender does not need to do any retransmissions; losses are repaired by the new packets that is sent out.
One place where this kind of technique could be used would be when a new, large, software package such as KDE, GNOME, or the Linux kernel, is to be distributed to a large number of receivers. The sender would just send data in a fixed rate and the receivers would just have to "tune in" to the data stream. After some time, the whole package is received. No more spikes in bandwidth consumption and no more slashdot effects.
My thoughts exactly - it runs fast, lean and most amazing of all, switches into and out of graphics mode (direct hardware hitting, even!) without causing NT to gripe! I am still trying to figure that out (hey, l33t ASM coder I am not).
Actually, switching in and out of graphics mode is the least of problems with writing stuff such as this. Switching to 320x200 mode is done by those two lines of code:
mov al,13h
int 10h
Switching back to text mode is done by:
mov al,03h
int 10h
Is it really fair to say that they are profiting from free software? Their plugin exists because people want to be able to run proprietary software in the form of web browser plugins. People wouldn't buy the CrossOver plugin if all Windows based plugins were free software - in that case, people could just download the source for the Windows plugins and compile them for themselves.
I think it is more fair to say that they are making their profit from the proprietary Windows based plugins that their software is able to run. Eventhough these plugins are free (as in beer).
All ISPs which I am familiar with say the same about Linux, *BSD, or any other kind of operating system which isn't Windows 95/98 or MacOS. It just means that they can say "sorry, we don't support your system" whenever there is a problem and you run an "exotic" system even when the problem happens to be within their system.
I tend not to reveal that I run a non-supported system when I report problems...
If you think that 64k is small, check out the amazing Omnicent demo. This is a (non-playable) clone of the good old 3D game Descent, but coded in 4096 bytes, including wall textures and music! Furthermore, it doesn't require any extra hardware or software; it runs under MS-DOS and draws directly to the VGA card.
Take a look at http://c64.cc65.org/. It is a good old C64 working as a web server. It runs the uIP TCP/IP stack, which is written in C and is really tiny; the code is around 4k large and it uses some 200 bytes of RAM.
I couldn't agree more. Testing is incredibly important for software projects and automated tests makes sure that certain test are not forgotten.
GCC has a test suite: http://gcc.gnu.org/testresults/ and uses the test suite as a formal release criterion. The GCC team also uses those tests as benchmarks for the compiler.
- "Toy" systems that are written by a few hackers "just because they can". Those are typically written in (x86) assembler and even eary versions can produce a nice looking GUI. (Note that "toy" systems can very rigid and functional, despite their name.)
- "Research" systems that are written by researchers to prove a point. The rarely have a GUI (unless the research involve real-time graphics as for Nemesis).
Both kinds are extremely hard to install, only run on a very carefully selected set of hardware, and don't really gain much appreciation other than from a very small group of followers. Followers from both groups often look down on eachother.Lately, the operating systems research has come to a slowdown, but the operating system hackers (that produce the "toy" systems) are gaining more and more momentum. The latter can most likely be contributed to the success of Linux. Can the former be explained by that operating systems now is a fully explored area?
IMHO, what's needed is a GUI that'll do for X what RISC architectures did for processors. Produce a MUCH simpler underlying architecture, using layers to provide more and more complex functionality.
But isn't this exactly what X is? The X server is just a very dumb program that only knows how to draw lines, boxes, circles, and fonts. Everything else (i.e., the complexity) is layered on top of this through toolkits and window managers.
A GNOME program uses the simple GTK toolkit to provide the GUI. GTK uses Xlib which uses X. The complexity is layered.
Furthermore, neither the application nor the toolkit needs to worry about how the window is managed; this is taken care of by the window manager program. The window manager interacts with the user and moves, resizes, and iconifies windows. Layered complexity once again.
If that isn't flaimbait, then what is!?
Has the GPL ever been successfullly enforced?
In fact, this has nothing to do with the GPL. This is how the copyright laws work; you cannot distribute a program that you don't hold the copyright to, unless the copyright holder has granted you permission to redistribute the program.
The GPL gives everyone the permission to redistribute the program, provided that they follow the requirements stated in the GPL. Those include, among other things, that it must be possible to obtain the source code for the entire program, including modifications.
So, this case does not really have anything to do with the GPL. It is a standard case where copyright has been breached.