One of two things can happen here: either the gov't (in the form of the NSA) can buy the patents in some way or another, or we can just wait around until Secure Computing realizes that few will adopt SELinux, and Secure Computing may get sued for GPL violation if they attempt to sell restrictive licenses.
I bought a Matsonic SiS-630-based motherboard and the DiskOnChip Millenium so I could build a solid-state box using
LinuxBIOS. This ought to fit nicely.
Anybody know where to buy a small (set-top sized) case for a Micro-ATX motherboard? I don't need any space for drives, because it won't have any.
With Kiem Phong Vo and others, you have espoused a number of library design principles (e.g., use of (stackable) disciplines and proper exception handling) and used them to great effect in sfio and other libraries. Sfio, in particular, is just so much better than stdio that every time I use the latter I cringe.
Unfortunately, these libraries seem to have not been widely adopted by the free software community since they were opened. (Perl can use sfio; other examples?) What do you think is needed to change that? Licensing? Perhaps distribution in the base packages of the free operating system distros? More documentation/tutorials/examples? These packages have their own auto-configuration feature test tool (iffe) and build scripts that differ in the details from the "./configure ; make ; make install" procedure common to much free software. Would it be helpful to convert them to use autoconf, for example?
It seems a terrible shame that more programmers are not exposed to the library construction and reuse principles in Sfio, Cdt, Vmalloc. If these libraries were in everyday use, we'd probably see more code written in that style.
Can you see Plex86 being adapted for instrumentation of code? It seems at first glance that the "scan-before-execute" architecture might be used to instrument pages to keep track of counters, memory and i/o references, watchpoints, etc. This could be done for ordinary Linux userland executables, as well as entire operating systems running under Plex86.
There are other free instrumentation and probing efforts underway, like the Linux Trace Toolkit and the IBM dprobe work, but they don't really seem suitable for things like (1) tracing every memory reference or (2) profiling all basic-blocks.
Perhaps IBM's Daisy project would be better suited to this type of instrumentation. Thoughts?
If Transmeta were to provide an API to expose their cache to Linux (and potentially other operating systems), then the translated code could be saved in the filesystem or swap and reloaded as needed. This would remove the code morphing penalty and decrease memory pressure. This would be similar to what is done on AS/400.
Yeah, Red Hat botches a lot of things in their.0 releases; then they fix them. Who else was going to do the hard work of stabilizing support for ELF, glibc, etc.? I'll agree with one thing though; perhaps they should have put that.0 on RH7.:-)
One minute everyone is complaining that some distro is shipping an old version (that had survived much QA), and the next minute they are complaining that a new version is broken. Look folks, there is a lot of code out there, written by a far-flung assortment of people who have differing opinions of release-quality. If you are using a package, the only important opinion is your own.
I hate tracking down problems as much as the next guy, but I don't expect an error-free distribution from Red Hat (or anyone else) any more than I expect Linus to ensure that every kernel driver is functioning properly. What I do want (and almost always receive in the free software world) is a constructive dialogue when there is a problem.
Companies like Sun like to talk about customer "service", but they have only fixed one of the dozens of bugs that I have identified and reported over the years in anything close to a timely fashion (1 year!). Broken SCSI (Adaptec) and Ethernet (3c905) drivers, sh (core dumps), sort (wrong order), join (wrong results), curses (row/columns > 127 ?!?),... and on and on.
Ah hell, just use the GNU stuff; it may not be POSIX.2, but at least it gives correct results.:-/
Ingo did a preliminary patch for this a while ago, as part of his low-latency work. It appears that MontaVista has picked up the ball and run with it. Integrating a patch like this is going to require a lot of QA, so it should go in early in the 2.5 cycle -- this is definitely not something that one throws in at the last minute.
It will be interesting to see how much the preemption infrastructure impacts performance (throughput) on a uniprocessor.
On a perhaps related note, I've been thinking about the growth of locks in the kernel. Many of these will have little contention, and locking is a pessimistic approach that incurs overhead. Plus, more locks means more locking discipline required.:-/ Anybody have a good reference to lockless data structure, algorithm, and design techniques?
Would a (functional, executable) series of implementations of the DeCSS algorithm in progressively higher-level languages be helpful on appeal? Perhaps in a Zork-like pseudo-English? I've got no time to do this, but all you students taking your first Lisp/Scheme class, consider this a homework assignment.:-)
Damn you Ingo! With all your page cache, IO-APIC, interrupt binding, and now TUX changes, coupled with Alexey and Dave's softnet and Al Viro's VFS changes, my crappy SMP machine will simply cook itself. Can you slow 2.4 down before lm_sensors goes off the scale and my chipset melts?:-)
This could be dicey, but you could build OpenSSH for SSH2 only, and exclude RSA from the openssl build. The code would still be in the pristine sources, but would not be built.
Building this way was broken a few releases back, (due to header files) but I think it may be fixed now.
In any case, September 21 it doesn't matter any more. I can't wait to see a secure-out-of the box distro with openssh and gpg; this really needs to be integrated with useradd...
You are on the right track. TCP/IP has ICMP packets, TCP options, sequence and port numbers,... lots of fun places to hide information.
Covert channel idea: Send data in the checksum of a packet, perhaps by varying the packet sizes, changing whitespace in text, etc. and use encryption to randomize that. It doesn't have to be the simple checksum, it could be CRC (which requires a bit of linear algebra to do the tampering).
The Dis VM performance is far superior to the JVM, because it uses a register model that is close to actual architectures. So the Dis bytecode compiler basically maps Dis bytecodes to machine instructions, doing a bit of virtual->actual register allocation along the way. Claimed performance is a third to half the speed of compiled C, and the bytecode translator is a few thousand lines of code. The JVM stack architecture is fine for a college term project, interpreter, but not global deployment -- it takes lots of optimization resources to transform a stack-based program to efficiently use registers. This should be done once in the compiler, not in the bytecode translator. Java JITs are massive behemoths because of this fundamental mistake. Also, Java garbage collection stinks, and Java lacks the channels of Limbo. The Java language also needs generics. Limbo has its own problems, and Lucent did a miserable job of marketing Inferno. But Pike, Ritchie, et al are good engineers -- they get the design right, and then refine the implementation.
The real problem with Rambus is that Intel tried to squeeze the market for RAM, the same way it has tried with chipsets, graphics, and networking. And it is getting kicked in the teeth everywhere. Didn't they learn anything from IBM's MCA disaster?
NFS -- traditional standards play; crappy design and code licensed to others. Independently implemented in Linux.
PAM -- pretty good design; implemented better in Linux than in Solaris.:-)
ELF -- traditional standards play; pretty good design. Independently implemented in Linux and GNU toolchain.
NSS -- pretty good design; independently implemented in glibc2.
Java -- traditional standards play; OK language (missing generics, closures, etc.), amateurish VM (stack-based? WTF?), poor libraries and environment (but improving). See Inferno for lessons in good design.
StarOffice -- perhaps useful, but bloated and non-free
So yes, Sun has documented some useful designs, and released ONC-RPC to the world. So what? They also distribute binaries of lots of code that they got elsewhere under a BSD license (starting with Unix!), and their versions are often broken...
Yeah, why not GUILE instead? Stallman is right when he says (I paraphrase) that most scripting languages (and configuration languages) are simply poor implementations of Lisp. What needs to be done is to take the *semantics* of a language like Scheme, and get rid of the damn parentheses.:-) Actually, I kind of like Mathematica; the notation is related to the original M-expressions for List (see Guy Steele's "The Evolution of Lisp").
Do you realize that nobody really cares? Aside from bragging rights, it just doesn't matter. What is important is that Samba can be run on a reliable, easily administered platform.
Although many in the BSD crowd earn my disdain, I have nothing but respect for Hubbard. An award to Hubbard from the FSF would be a great symbolic gesture.
I came to the conclusion a long time ago that in the great Linux epic, Linus is like Achilles (blessed of the gods, full of talent, and eminently marketable...); Alan is Aias (Ajax): a mortal, who in his boundless energy and determination, crushes all obstacles in his path and strikes fear even in gods who would oppose him. (Remember, it was Alan that the BillG tried to turn.:-)
Slashdot Mirror
One of two things can happen here: either the gov't (in the form of the NSA) can buy the patents in some way or another, or we can just wait around until Secure Computing realizes that few will adopt SELinux, and Secure Computing may get sued for GPL violation if they attempt to sell restrictive licenses.
Anybody know where to buy a small (set-top sized) case for a Micro-ATX motherboard? I don't need any space for drives, because it won't have any.
With Kiem Phong Vo and others, you have espoused a number of library design principles (e.g., use of (stackable) disciplines and proper exception handling) and used them to great effect in sfio and other libraries. Sfio, in particular, is just so much better than stdio that every time I use the latter I cringe.
Unfortunately, these libraries seem to have not been widely adopted by the free software community since they were opened. (Perl can use sfio; other examples?) What do you think is needed to change that? Licensing? Perhaps distribution in the base packages of the free operating system distros? More documentation/tutorials/examples? These packages have their own auto-configuration feature test tool (iffe) and build scripts that differ in the details from the "./configure ; make ; make install" procedure common to much free software. Would it be helpful to convert them to use autoconf, for example?
It seems a terrible shame that more programmers are not exposed to the library construction and reuse principles in Sfio, Cdt, Vmalloc. If these libraries were in everyday use, we'd probably see more code written in that style.
Amazing work Kevin!
Can you see Plex86 being adapted for instrumentation of code? It seems at first glance that the "scan-before-execute" architecture might be used to instrument pages to keep track of counters, memory and i/o references, watchpoints, etc. This could be done for ordinary Linux userland executables, as well as entire operating systems running under Plex86.
There are other free instrumentation and probing efforts underway, like the Linux Trace Toolkit and the IBM dprobe work, but they don't really seem suitable for things like (1) tracing every memory reference or (2) profiling all basic-blocks.
Perhaps IBM's Daisy project would be better suited to this type of instrumentation. Thoughts?
All the more reason to trust Theo with your security. :-)
If Transmeta were to provide an API to expose their cache to Linux (and potentially other operating systems), then the translated code could be saved in the filesystem or swap and reloaded as needed. This would remove the code morphing penalty and decrease memory pressure. This would be similar to what is done on AS/400.
Yeah, Red Hat botches a lot of things in their .0 releases; then they fix them. Who else was going to do the hard work of stabilizing support for ELF, glibc, etc.? I'll agree with one thing though; perhaps they should have put that .0 on RH7. :-)
... and on and on.
:-/
One minute everyone is complaining that some distro is shipping an old version (that had survived much QA), and the next minute they are complaining that a new version is broken. Look folks, there is a lot of code out there, written by a far-flung assortment of people who have differing opinions of release-quality. If you are using a package, the only important opinion is your own.
I hate tracking down problems as much as the next guy, but I don't expect an error-free distribution from Red Hat (or anyone else) any more than I expect Linus to ensure that every kernel driver is functioning properly. What I do want (and almost always receive in the free software world) is a constructive dialogue when there is a problem.
Companies like Sun like to talk about customer "service", but they have only fixed one of the dozens of bugs that I have identified and reported over the years in anything close to a timely fashion (1 year!). Broken SCSI (Adaptec) and Ethernet (3c905) drivers, sh (core dumps), sort (wrong order), join (wrong results), curses (row/columns > 127 ?!?),
Ah hell, just use the GNU stuff; it may not be POSIX.2, but at least it gives correct results.
Ingo did a preliminary patch for this a while ago, as part of his low-latency work. It appears that MontaVista has picked up the ball and run with it. Integrating a patch like this is going to require a lot of QA, so it should go in early in the 2.5 cycle -- this is definitely not something that one throws in at the last minute.
:-/ Anybody have a good reference to lockless data structure, algorithm, and design techniques?
It will be interesting to see how much the preemption infrastructure impacts performance (throughput) on a uniprocessor.
On a perhaps related note, I've been thinking about the growth of locks in the kernel. Many of these will have little contention, and locking is a pessimistic approach that incurs overhead. Plus, more locks means more locking discipline required.
Why not drop them all on New Year's Eve, and recoup some money from party organizers? :-)
Would a (functional, executable) series of implementations of the DeCSS algorithm in progressively higher-level languages be helpful on appeal? Perhaps in a Zork-like pseudo-English? I've got no time to do this, but all you students taking your first Lisp/Scheme class, consider this a homework assignment. :-)
Errrp -- wrong answer. Check handhelds.org -- xscribble offers Graffiti(tm)-like character recognition for Linux handhelds. But thanks for playing.
Damn you Ingo! With all your page cache, IO-APIC, interrupt binding, and now TUX changes, coupled with Alexey and Dave's softnet and Al Viro's VFS changes, my crappy SMP machine will simply cook itself. Can you slow 2.4 down before lm_sensors goes off the scale and my chipset melts? :-)
This could be dicey, but you could build OpenSSH for SSH2 only, and exclude RSA from the openssl build. The code would still be in the pristine
...
sources, but would not be built.
Building this way was broken a few releases back, (due to header files) but I think it may be fixed now.
In any case, September 21 it doesn't matter any more. I can't wait to see a secure-out-of the box distro with openssh and gpg; this really needs to be integrated with useradd
Thanks for a great distro.
You are on the right track. TCP/IP has ICMP packets, TCP options, sequence and port numbers, ... lots of fun places to hide information.
Covert channel idea: Send data in the checksum of a packet, perhaps by varying the packet sizes, changing whitespace in text, etc. and use encryption to randomize that. It doesn't have to be the simple checksum, it could be CRC (which requires a bit of linear algebra to do the tampering).
Then you use a transform technique and error-correcting coding.
The Dis VM performance is far superior to the JVM, because it uses a register model that is close to actual architectures. So the Dis bytecode compiler basically maps Dis bytecodes to machine instructions, doing a bit of virtual->actual register allocation along the way. Claimed performance is a third to half the speed of compiled C, and the bytecode translator is a few thousand lines of code. The JVM stack architecture is fine for a college term project, interpreter, but not global deployment -- it takes lots of optimization resources to transform a stack-based program to efficiently use registers. This should be done once in the compiler, not in the bytecode translator. Java JITs are massive behemoths because of this fundamental mistake. Also, Java garbage collection stinks, and Java lacks the channels of Limbo. The Java language also needs generics. Limbo has its own problems, and Lucent did a miserable job of marketing Inferno. But Pike, Ritchie, et al are good engineers -- they get the design right, and then refine the implementation.
The real problem with Rambus is that Intel tried to squeeze the market for RAM, the same way it has tried with chipsets, graphics, and networking. And it is getting kicked in the teeth everywhere. Didn't they learn anything from IBM's MCA disaster?
Why source? Because Linux and *BSD run on every microprocessor out there. Do you think they are going to give you a NetBSD/Vax binary version?
FREEDOM!
Get a clue, please.
RPC/XDR -- yes, crappy design, but thank you Sun.
:-)
...
NFS -- traditional standards play; crappy design and code licensed to others. Independently implemented in Linux.
PAM -- pretty good design; implemented better in Linux than in Solaris.
ELF -- traditional standards play; pretty good design. Independently implemented in Linux and GNU toolchain.
NSS -- pretty good design; independently implemented in glibc2.
Java -- traditional standards play; OK language (missing generics, closures, etc.), amateurish VM (stack-based? WTF?), poor libraries and environment (but improving). See Inferno for lessons in good design.
StarOffice -- perhaps useful, but bloated and non-free
So yes, Sun has documented some useful designs, and released ONC-RPC to the world. So what? They also distribute binaries of lots of code that they got elsewhere under a BSD license (starting with Unix!), and their versions are often broken
Completely different economic and business model. MS and IBM have about as much in common as MS and Standard Oil.
Completely economic and business model. MS and IBM have about as much in common as MS and Standard Oil.
Yeah, why not GUILE instead? Stallman is right when he says (I paraphrase) that most scripting languages (and configuration languages) are simply poor implementations of Lisp. What needs to be done is to take the *semantics* of a language like Scheme, and get rid of the damn parentheses. :-)
Actually, I kind of like Mathematica; the notation is related to the original M-expressions for List (see Guy Steele's "The Evolution of Lisp").
Do you realize that nobody really cares? Aside from bragging rights, it just doesn't matter. What is important is that Samba can be run on a reliable, easily administered platform.
Although many in the BSD crowd earn my disdain, I have nothing but respect for Hubbard. An award to Hubbard from the FSF would be a great symbolic gesture.
I came to the conclusion a long time ago that in the great Linux epic, Linus is like Achilles (blessed of the gods, full of talent, and eminently marketable ...); Alan is Aias (Ajax): a mortal, who in his boundless energy and determination, crushes all obstacles in his path and strikes fear even in gods who would oppose him. (Remember, it was Alan that the BillG tried to turn. :-)