I have login and logout scripts for managing and ssh agent. The first time I log into my system, it starts and ssh agent. It records three things into a file: the agent's PID, a reference count initialized to 1, and the agent's socket.
Subsequent login sessions simply use the existing information and bump up the reference count.
The logout script decrements the reference count, and if it reaches zero, it kills the agent. Thus so long as I have at least one remaining shell, the agent is running, and I don't have to retype the password phrase.
A little extra subtlety takes care of cases like nested subshell invocation and so on. A kill -0 is used to verify whether the agent is running, which takes care of cases when the reference file is bad (e.g. reboot without logging out).
There are no concurrency controls in the reference counting, the assumption being that I will never switch between shells fast enough to create a race among two or more logouts or logins.
If I wanted to, I could change from reference counting to a system which keeps the agent persistent, but I don't entirely like the idea of leaving the agent running when I'm not logged in.
If any ssh user wants these scripts, just write me!
The measurements of keystroke timing can be done on a broad, high-latench internet only if the Nagle algorithm is disabled. Some SSH implementations defeat the use of Nagle, in order to provide better interactive response. This can be taken out in the source code (or maybe with a configuration parameter: I'm not familiar with all SSH implementations).
When you have Nagle enabled, your keystrokes are aggregated into larger packets, because the next packet is not sent until an ACK for the previous one is received---or you type enough to send a full segment. Or something like that; I leave it to the reader to verify the details of Nagle. In any case, it's clear that Nagle can obscure the timing of individual keystrokes if the latency is high enough to cause aggregation of several characters into one packet.
Secondly, if you use public key authentication, then you won't be typing your SSH password over the network. Of course, other sensitive information may be typed, such as passwords to other systems logged into within the SSH sessions. But the SSH key itself can't be compromised by this timing attack.
I think I was thinking ``Dr. Pangloss'' in my head when I wrote that, the character from Voltaire's _Candide_ whose irrational optimism in stark contrast to Matloff's pessimism.;)
I know about him from Usenet, because once in a while, some mentally retarded rednecks cross-post an anti-immigration flamewar to the comp.lang.* newsgroups, and they like to cite this document as an excuse for posting racist, xenophobic diatribes about how filthy immigrants are taking away white jobs. It's nothing new.
Note the copyright dates on the document (C) 1998 through 2001.
Funny that it took Slashdotters this long to stumble across it. Maybe that's because it's so full of crap that nobody is paying attention to it.
This is certainly not news (for nerds, or anyone).
The one point of interest is the 0, which is the termination status of the most recently executed command. This is obtained from bash simply by inserting $? into the PS1 variable.
I got this termination-status-embedding-in-prompt idea from Tanmoy Bhattacharaya.
Chinese law doesn't support IP, and therefore the GPL is uneeded there. Isn't this what all of you want eventually?
Not quite. If copyright didn't exist, there would still be the problem of binary-only code. The absence of copyright would remove most, though not all, of the reasons why some assh^H^H^H^Hindividual or group would want to keep a user base hostage with binary code.
Environment variables are nice because they give you an easy way to pass different configuration to multiple instances of the program. (Argument vectors can do the same thing, but are not always as convenient: for example, what if you have a whole suite of related programs that share configuration information?) On the other hand, you probably don't want to pass a large number of settings via environment variables.
One popular combination is to use an environment variable to point the program suite to a configuration file or directory of configuration files.
The threading library LinuxThreads has to play the violin while standing on its head to make threads look POSIX-like. The kernel people look upon POSIX threads as braindamaged, and they are largely right.
In my view, most of the noncompliances that exist actually make LinuxThreads a better library. For example fcntl() locks are owned by threads rather than the ``process''. This is more natural to program with; you don't want a locking request by one thread to just proceed even though it overlaps with an existing lock held by another thread in the same process! Think of the race condition bugs that can cause. Yet that's what POSIX requires. It's evident that POSIX is largely driven by vendors who have operating systems on which it's easier to hack threads this way, as sort of dadoes that are engraved into processes.
Another braindamaged area of POSIX is that all threads share the same current working directory. This is upheld by LinuxThreads using CLONE_FS,
but in principle it doesn't have to be. Again, think of the bugs this can cause! One thread does a chdir(), and the file accesses done by another thread go beserk into another directory.
Then there is the whole problem of security contexts. In POSIX, your effective and real user and group ID's are process-wide; if a thread changes user ID, it changes it for all threads. Like chdir, changes in user ID *need* to be done in a procedural discipline, regardless of what you may think of the idea of having multiple security contexts in one address space. Think you can fork() around the user ID problem? If you fork() in a POSIX threaded process, the child can use only async-safe functions, or the behavior is undefined. If you need to do more things, you must exec() a new image.
On the other hand, there are some reasonably nice behaviors in POSIX that don't work on Linux, like doing a fork() in one thread, but doing the wait() in another. (Workaround: make a fork server thread which handles fork and wait requests on behalf of others).
When they talk about performance, they might, e.g., have in mind a $100,000 multi-proc web application server running hundreds or even thousands of threads in parallel, with several thousand more requests in queue.
Again, using thousands of threads is not going to get the best performance out of it, if it does not actually have thousands of CPU's or network cards or disks. A reasonably small pool of threads is all it takes. You need a thread for each peripheral you ever need to wait for, and each processor you need to keep busy, and then some.
There is no special set of processing principles for a $100,000 server which say that you can stuff in any number of threads. Of course, with a larger address space, memory and greater memory bandwidth, you can be more wasteful and notice it less.
The way I see it, this IBM project is just reinventing LinuxThreads with a few differences, the biggest being M:N threading. If you look at their list of known issues listed in the release notes, it's about the same as for LinuxThreads: no process shared mutexes, no process identity for threads (except when only one underlying system task is used). These two are the biggest sources of complaints from some LinuxThreads users.
The rest of my comments have to do with M:N, specifically the false claim that M:N provides a performance enhancement for all multithreaded applications.
I don't believe that M:N threading is a good idea It creates issues and complications in the library implementation. The responsibility of scheduling and dispatching is divided between user space and the kernel instead of being done in one place. What M:N threading does is speed up voluntary context switches---context switches that take place within a threading function that is directly or indirectly invoked by the application, such as a synchronization function (pthread_cond_wait, pthread_mutex_lock, etc). Such a function can just call the user space scheduler, which can dispatch a thread without cooperation from the kernel. This is how M:N reduces overhead.
M:N does nothing for involuntary context switches, which have to somehow go through the kernel (for example, a signal is delivered to the process, which swaps context so that returning from the handler will cause a new thread to run). Actually, this kind of context switch can be worse than the ordinary Linux kernel context switch, depending on how it is done. The current task is interrupted to run kernel code (transition 1). Then a handler in user space is dispatched (transition 2). Then the handler returns to the kernel (transition 3) then the kernel passes control back to user space with a new context (transition 4). On the other hand, a native context switch is just two transitions: interrupt the current task, and dispatch the new one. In any case, the kernel is involved in the involuntary context switches of the so-called ``user space'' scheduler, which puts their expense in about the same ballpark as a kernel task switch (within the same address space).
So what about the faster voluntary context switches that M:N provides? Unfortunately, most of the *useful* voluntary context switch points are in the kernel: such as blocking calls that wait for I/O or real-time events. So M:N does nothing for I/O or response to real-time inputs. Dispatching a response to the completion of I/O or a real time input always requires a switch from the kernel to the user process.
M:N also does nothing for compute-intensive multithreading that is done *sanely*. Sure, M:N may speed up a program that performs, say, some operation on a large matrix using 50 threads on two processors, because when these threads synchronize, it can be done using those fast voluntary context switches. But M:N will do nothing for a program that uses two threads over two processors to do the same thing, which is the more sane design.
As a rule, the number of threads in an application should be not much more than the minimum that is required to utilize the various functional units of the hardware (processors and peripherals). Using too many threads just causes wasteful context switches that accomplish nothing, increases the memory access footprint of the application (since each thread has its own private data areas, such as the stack), and causes the scheduler to have to choose from among more threads.
It's not worth trying to speed up brain-damaged applications that make poor use of threads, yet this is exactly what M:N is for.
You must disregard the critics and just forge onward with your creativity. The only form of acceptance that matters, if acceptance matters at all, is that by enthusiastic fans of your work.
A creation is art if it exhibits creativity, style and can carry some kind of emotional or intellectual message that appeals to or provokes the mind at some level.
Ray tracing two spheres over a checkered plane is probably not art, but not on account of being computer rendered, but on account of the tiny amount of actual creative input. It's the computer graphic equivalent of throwing a can of paint at the canvas, or painting a few geometric figures; the idea is small, and its translation into the final work is mechanical or random.
Art lies in that region of complexity somewhere between randomness and uniformity.
If the criticism you are receiving is simply about the medium you are using, rather than the forms you are creating within that medium, then that is pure elitism. You should discount that immediately. Any criticism that is not related to what you are actually creating, but to your unorthodox method of creation, should not be considered valid criticism at all.
You have to remember that in the world of art, the value of an artwork is judged by things other than its content. A ridiculously high value is ascribed to an original paining, for instance, even though a faithful replica carries the same information.
In computer graphics, there is no such thing as an original; all copies are equivalent. I suspect that this has a lot to do with why the players in the art world are so disparaging of computer art. You can't do the same kind of wheeling and dealing! A gallery cannot say that it has the original work of some computer graphic artist. A computer file at an surreal price.
(Okay, what you could do is make a one and only print, and then destroy all the digital artifacts that went into it, but I think that digital artists regard those digital artifacts as the real work of art; who wants to destroy their work?)
Suppose you could have a large cluster of small computers to compute things which are highly parallelizable. This cluster should probably be arranged in a sphere to make the computers as close together as possible. The source of computation requests would probably be placed in the centre of the sphere. So the turnaround time of the computers on the surface of the sphere is then bounded by the time needed for light to travel the radius of the sphere twice. To keep the outer computers busy, you need a longer queue of processing requests. Any pointers to papers about this?
I'd like to see an analysis for the breakeven point; for what problems would a sphere of a given radius containing computers of a given speed provide a speedup, such that any larger radius would diminish the return, despite adding to the aggregate computing power?
Come on, you read Ballmer. This is just ``fair compensation'' for copies of your ``intellectual property''.
Emissions is one reason! Then weight, etc.
on
Hardwoodware
·
· Score: 2
The computer's guts have to be surrounded by a conductive jacket that is grounded, so that no electromagnetic radiation can escape. The FCC, or similar bodies elsewhere, would not approve of an unshielded case.
So if you have a wooden case, it still needs a layer of shielding, either on the inside our outside. So you might as well just make the case out of sheetmetal and dispense with the wood.
Then there is the weight, and the fact that wood is a good thermal insulator.
I think that cost could be an issue for cases made of a quality hardwood. The whole idea here, to me, is to get an esthetic cabinet made of a finer material; making it out of plywood or MDF kind of defeats the purpose, since these materials are inferior to metal or even plastic. (Yet, people *will* buy particleboard garbage if it has veneer---this is the founding principle behind IKEA, for instance). The cost for cranking out pine, plywood or MDF cases in high volumes is probably not much greater than ordinary cases, but once you get into the better hardwoods, it gets more expensive. Never mind oak, how about a case made of bubinga, wenge and other such hardwoods? Why stop at cases? I'd like a keyboard made of zebrawood, with ebony keycaps, either without labels or labels made using mother-of-pearl inlay.;)
``For use on * operating systems only'', where * represents free, or whatever other non-functional attribute, is clearly a case of the vendor imposing his will to restrict uses of the software which do not affect anyone else but the user. The vendor is taking away certain freedoms from the user, freedoms which don't encroach on other people's freedoms. So this is a foul restriction in the light of a basic freedom principle, namely that what other people do is their business if it doesn't affect you.
Note that the GNU license doesn't restrict uses of software, only that redistribution of the software, when it occurs, should happen in certain ways which promote the freedom. The license takes away only one freedom: the freedom to impose a reduced freedom on others.
You still don't seem to get it.
on
Mundie Responds
·
· Score: 2
If you want to feed one million people, you have to produce one million meals. If you want to clothe one million people, you have to make one million outfits.
If you want to get one million people to each run a web server, they obviosuly need up to a million computers to run them on and a network. But you only have to give them *ONE* web server program!
Whereas the software-duplication industry claims that no, you have give these people one million programs (which happen to be identical), that each copy is in effectively a new program, a new product of the software industry. Moreover each new such product contributes to the economy. At least this is what apologists like Mundie claim when it suits their anti-free-software agenda. When it comes to the anti-piracy agenda, the spin is different. Then it is readily admitted that there is in fact only one program which is the sole property of the vendor, and the users are merely granted a license to execute one copy of that program at a time. So the users do not in fact own any product, only some limited permission.
Re:The economic argument is pure sophistry.
on
Mundie Responds
·
· Score: 2
Mart, I don't disagree that software can cause economic growth. However, I'm saying that *sales* of *copies of software* are not themselves economic growth.
It's clear to me that the execution of software on a computer can contribute to economic growth whether or not that software is freely redistributable and maintainable by its users.
Now Mundie makes the argument that it's the direct sales of software with a proprietary license which contributes to economic growth, and then he quotes some revenue numbers to back that up. I'm saying that those revenue numbers are simply evidence of a kind of transfer payment, effectively a tax, and not of economic growth.
The people using that software could have made their own copies of it, and could be just as productive by having their computers execute those copies, and so whatever economic benefit there is exists regardless of the transfer payment.
Of course, the common argument is that the software wouldn't exist in the first place if it weren't for the venture capitalists who undertook risks to fund its development, and need to keep the software proprietary to recover their costs.
That's like arguing that housework won't get done if we can't keep slaves.
Re:The economic argument is pure sophistry.
on
Mundie Responds
·
· Score: 2
The value of an Apache binary is its ability to execute. Yes, it certainly is no more difficult to make copies of that apache binary than to make copies of a string of all-zero bits. The actual bits of the binary do not have any value. The program source of course has a lot of value, undoubtedly. It's valuable that there is a single idea called Apache embodied in copies of source code.
When you produce something tangible, the structure of that thing dictates the difficulty of producing more copies of it. For example, a Rolex watch is arguably more demanding to produce than a $5 dollar plastic digital watch, due to the materials, demand for precision, more use of custom parts, and so on. So we say that the Rolex has a greater value.
I also disagree with your naive claim that clothing is easily replicated. If so, why isn't everyone you doing it? I would certainly replicate my clothing if it were possible. Why don't all clothing consumers put in the equipment investment and labor to ``replicate'' their own clothing?
Perhaps you are confusing the ability to crank out a lot of clothing with replication. Mass production is achieved by having a lot of people sweat out each piece of clothing in parallel. If you trace the development of an individual clothing article through the production line, it will be obvious that what is going on is not replication, but construction. The method by which the clothing is assembled has to do with its structure: the procedure for making a shirt differs from the procedure for making a glove. Whereas replicating information is completely blind to the nature or complexity of its structure. The method for replicating information is a function of the source and target representation media, not of what is being copied.
So you see writing this kind of program or that is vaguely similar to sewing this kind of clothing article or that: compiler or editor, glove or shirt. Designing the program is somewhat similar to designing the clothing. But replicating the program, once it is finished---that has no analogy in clothing production! The program is an idea, not a thing. Two copies of the program are really just aliases for the same program, you do not really have two programs! If I state a true sentence twice, do I have two truths?
Didn't Edison simply steal the lightbulb idea from someone else? He also used gruesome public electrocutions of animals to scare people from adopting alternating current. This guy had the sowing of fear, uncertainty and doubt down to an art! No wonder Mundie invokes his name in awe.:)
He *did* make an argument that it's bad for users!
on
Mundie Responds
·
· Score: 2
Didn't you read the article? He makes a highly fallacious argument that free software is bad for the economy, because proprietary software is good for the economy. I made a top-level response to this nonsense elsewhere in this discussion.
So, if free software is bad for the economy, not only is it bad for the users of that software, but for everyone else! So this implies that the writers, and primarily the users of free software can be blamed for contributing to economic problems. Not only are the users parasites and freeloaders, but they contribute negatively!
Hey Mundie, why not just go right out and blame free software users for recent downturns in some sectors of IT?
I suspect that redneck patriotism is at the heart of Mundie's cloudy reasoning, in addition to greed and all that. Free software is un-American because pesky outsiders can connect to American FTP sites and download free software, instead of buying proprietary software. And of course, any worthwhile software, free or otherwise, is American; none of those foreign idjits know what they are doing. So therefore those who give software away are traitors who are robbing the number one country in the world from some of its software taxation income!
The economic argument is pure sophistry.
on
Mundie Responds
·
· Score: 3
Software doesn't actually have any value in and of itself. The companies which mass produce software and charge for it are not driving the economy in any way, they are simply taxing it!
When you sell software within your own country, you are simply redistributing wealth, not generating any. Money flows from the software users into the pockets of the software tycoons (who probably spend and invest a great lot of it abroad). There is no net economic gain in the transaction. Whenever this software-copying industry (let's call it what it is) makes a new CD, they are effectively printing their own money.
What drives the economy is real production of goods: think food, clothing, energy, transportation etc. Software can make the management of production more efficient in many direct and indirect ways, so it contributes to the value production indirectly. Individuals and organizations can be more efficient in certain ways if they have the right software. But it's the surplus created by the real industry which allows the technological priesthood to engage in pleasant intellectual diversions, such as the production of software, and then pretend they are doing some sort of all-important economic activity.
The value provided by software is related to *executing* the software. There is no intrinsic value in the actual ones and zeros which are replicated trivially and at low cost. Executing the software does not cause those ones and zeros to be consumed (unless they are specially contrived ones and zeros, comprising some kind of bullshit license, which can be circumvented, unlike the law of conservation of energy). On the contrary, those ones and zeros can be replicated with a cost that is not only small, but is invariant with the complexity of the software. All that is consumed when software is copied or executed is energy. The fallacious argument that Mundie is making rests on the premise that the ones and zeros in fact have the same kind of intrinsic value as grains of wheat or barrels of oil. The truth is that they only have a value to the ``intellectual property holder'', and they only have that value because some artificial law which entitles only them to make copies for others. Take away that law, and people will continue to write software---that much is clear! Only, according to Mundie, that software will no longer have value, even if its execution continues to provide the same value as ever. What he means is that it will no longer have taxation value to him.
Are you sure these guys are programmers? I put most of a whole company on WinCVS within the last half a year or so. Looking at the/home directory of my CVS server, I see about 70 accounts belonging to users who access CVS over RSH from Windows boxes. I, along with a few others, provide minimal support besides setting up new accounts.
I work in what is pretty much an ``all Windows shop'', yet somehow we managed to switch to using CVS instead of VSS (not quite entirely). A lot of the documentation is in Word.
However, I write all my documentation in LaTeX, using encapsulated PostScript for diagrams. This isn't a problem, because I can generate a PDF which is stored in CVS along with the text source files. I do this for software internal documentation as well as for presentation materials (slides).
Binary files are okay in CVS as long as they are derived objects rather than primary objects. What happens during a merge is that you merge the primary objects (LaTeX source files), and regenerate the derived binary object (PDF) from the primary sources and commit the results. However, when the primary objects are non-mergeable (e.g Word documents) you are in trouble. If two people modify the same Word document on separate branches, there is no way to merge other than by hand editing.
With LaTeX, the documentation can be broken into many files which are stitched together with \input directives. This was an advantage because at one point I was working in a small team on the same document. Using multiple files minimizes the amount of back and forth merging that takes place with concurrent development.
I have a few LaTeX macros which can be used to embed CVS keywords like $Id$ in a special way into the documents. The macro actually collects these into a file during latex processing. A special appendix is then added to the output which lists all of the source files and their versions. This is called the ``Bill of Materials'' and tells the reader exactly what versions of the files in CVS correspond to the hard copy.
Here is a good advocacy page you can throw at people who think that word processors are actually suitable tools for intelligent documenting: Word Processors: Inefficient and Stupid.
Slashdot Mirror
I have login and logout scripts for managing and ssh agent. The first time I log into my system, it starts and ssh agent. It records three things into a file: the agent's PID, a reference count initialized to 1, and the agent's socket.
Subsequent login sessions simply use the existing information and bump up the reference count.
The logout script decrements the reference count, and if it reaches zero, it kills the agent. Thus so long as I have at least one remaining shell, the agent is running, and I don't have to retype the password phrase.
A little extra subtlety takes care of cases like nested subshell invocation and so on. A kill -0 is used to verify whether the agent is running, which takes care of cases when the reference file is bad (e.g. reboot without logging out).
There are no concurrency controls in the reference counting, the assumption being that I will never switch between shells fast enough to create a race among two or more logouts or logins.
If I wanted to, I could change from reference counting to a system which keeps the agent persistent, but I don't entirely like the idea of leaving the agent running when I'm not logged in.
If any ssh user wants these scripts, just write me!
The measurements of keystroke timing can be done on a broad, high-latench internet only if the Nagle algorithm is disabled. Some SSH implementations defeat the use of Nagle, in order to provide better interactive response. This can be taken out in the source code (or maybe with a configuration parameter: I'm not familiar with all SSH implementations).
When you have Nagle enabled, your keystrokes are aggregated into larger packets, because the next packet is not sent until an ACK for the previous one is received---or you type enough to send a full segment. Or something like that; I leave it to the reader to verify the details of Nagle. In any case, it's clear that Nagle can obscure the timing of individual keystrokes if the latency is high enough to cause aggregation of several characters into one packet.
Secondly, if you use public key authentication, then you won't be typing your SSH password over the network. Of course, other sensitive information may be typed, such as passwords to other systems logged into within the SSH sessions. But the SSH key itself can't be compromised by this timing attack.
I think I was thinking ``Dr. Pangloss'' in my head when I wrote that, the character from Voltaire's _Candide_ whose irrational optimism in stark contrast to Matloff's pessimism. ;)
Note the copyright dates on the document (C) 1998 through 2001.
Funny that it took Slashdotters this long to stumble across it. Maybe that's because it's so full of crap that nobody is paying attention to it.
This is certainly not news (for nerds, or anyone).
The one point of interest is the 0, which is the termination status of the most recently executed command. This is obtained from bash simply by inserting $? into the PS1 variable.
I got this termination-status-embedding-in-prompt idea from Tanmoy Bhattacharaya.
PS1=$?:\h:\w\$
Not quite. If copyright didn't exist, there would still be the problem of binary-only code. The absence of copyright would remove most, though not all, of the reasons why some assh^H^H^H^Hindividual or group would want to keep a user base hostage with binary code.
Proponents of free software compare proprietary software to communism. Likewise, proponents of proprietary software liken free software to communism.
:)
Now we finally know which behavior is more in line with communism, seeing actual communists engaging in it.
Environment variables are nice because they give you an easy way to pass different configuration to multiple instances of the program. (Argument vectors can do the same thing, but are not always as convenient: for example, what if you have a whole suite of related programs that share configuration information?) On the other hand, you probably don't want to pass a large number of settings via environment variables.
One popular combination is to use an environment variable to point the program suite to a configuration file or directory of configuration files.
The threading library LinuxThreads has to play the violin while standing on its head to make threads look POSIX-like. The kernel people look upon POSIX threads as braindamaged, and they are largely right.
In my view, most of the noncompliances that exist actually make LinuxThreads a better library. For example fcntl() locks are owned by threads rather than the ``process''. This is more natural to program with; you don't want a locking request by one thread to just proceed even though it overlaps with an existing lock held by another thread in the same process! Think of the race condition bugs that can cause. Yet that's what POSIX requires. It's evident that POSIX is largely driven by vendors who have operating systems on which it's easier to hack threads this way, as sort of dadoes that are engraved into processes.
Another braindamaged area of POSIX is that all threads share the same current working directory. This is upheld by LinuxThreads using CLONE_FS,
but in principle it doesn't have to be. Again, think of the bugs this can cause! One thread does a chdir(), and the file accesses done by another thread go beserk into another directory.
Then there is the whole problem of security contexts. In POSIX, your effective and real user and group ID's are process-wide; if a thread changes user ID, it changes it for all threads. Like chdir, changes in user ID *need* to be done in a procedural discipline, regardless of what you may think of the idea of having multiple security contexts in one address space. Think you can fork() around the user ID problem? If you fork() in a POSIX threaded process, the child can use only async-safe functions, or the behavior is undefined. If you need to do more things, you must exec() a new image.
On the other hand, there are some reasonably nice behaviors in POSIX that don't work on Linux, like doing a fork() in one thread, but doing the wait() in another. (Workaround: make a fork server thread which handles fork and wait requests on behalf of others).
Again, using thousands of threads is not going to get the best performance out of it, if it does not actually have thousands of CPU's or network cards or disks. A reasonably small pool of threads is all it takes. You need a thread for each peripheral you ever need to wait for, and each processor you need to keep busy, and then some.
There is no special set of processing principles for a $100,000 server which say that you can stuff in any number of threads. Of course, with a larger address space, memory and greater memory bandwidth, you can be more wasteful and notice it less.
The way I see it, this IBM project is just reinventing LinuxThreads with a few differences, the biggest being M:N threading. If you look at their list of known issues listed in the release notes, it's about the same as for LinuxThreads: no process shared mutexes, no process identity for threads (except when only one underlying system task is used). These two are the biggest sources of complaints from some LinuxThreads users.
The rest of my comments have to do with M:N, specifically the false claim that M:N provides a performance enhancement for all multithreaded applications.
I don't believe that M:N threading is a good idea It creates issues and complications in the library implementation. The responsibility of scheduling and dispatching is divided between user space and the kernel instead of being done in one place. What M:N threading does is speed up voluntary context switches---context switches that take place within a threading function that is directly or indirectly invoked by the application, such as a synchronization function (pthread_cond_wait, pthread_mutex_lock, etc). Such a function can just call the user space scheduler, which can dispatch a thread without cooperation from the kernel. This is how M:N reduces overhead.
M:N does nothing for involuntary context switches, which have to somehow go through the kernel (for example, a signal is delivered to the process, which swaps context so that returning from the handler will cause a new thread to run). Actually, this kind of context switch can be worse than the ordinary Linux kernel context switch, depending on how it is done. The current task is interrupted to run kernel code (transition 1). Then a handler in user space is dispatched (transition 2). Then the handler returns to the kernel (transition 3) then the kernel passes control back to user space with a new context (transition 4). On the other hand, a native context switch is just two transitions: interrupt the current task, and dispatch the new one. In any case, the kernel is involved in the involuntary context switches of the so-called ``user space'' scheduler, which puts their expense in about the same ballpark as a kernel task switch (within the same address space).
So what about the faster voluntary context switches that M:N provides? Unfortunately, most of the *useful* voluntary context switch points are in the kernel: such as blocking calls that wait for I/O or real-time events. So M:N does nothing for I/O or response to real-time inputs. Dispatching a response to the completion of I/O or a real time input always requires a switch from the kernel to the user process.
M:N also does nothing for compute-intensive multithreading that is done *sanely*. Sure, M:N may speed up a program that performs, say, some operation on a large matrix using 50 threads on two processors, because when these threads synchronize, it can be done using those fast voluntary context switches. But M:N will do nothing for a program that uses two threads over two processors to do the same thing, which is the more sane design.
As a rule, the number of threads in an application should be not much more than the minimum that is required to utilize the various functional units of the hardware (processors and peripherals). Using too many threads just causes wasteful context switches that accomplish nothing, increases the memory access footprint of the application (since each thread has its own private data areas, such as the stack), and causes the scheduler to have to choose from among more threads.
It's not worth trying to speed up brain-damaged applications that make poor use of threads, yet this is exactly what M:N is for.
You must disregard the critics and just forge onward with your creativity. The only form of acceptance that matters, if acceptance matters at all, is that by enthusiastic fans of your work.
A creation is art if it exhibits creativity, style and can carry some kind of emotional or intellectual message that appeals to or provokes the mind at some level.
Ray tracing two spheres over a checkered plane is probably not art, but not on account of being computer rendered, but on account of the tiny amount of actual creative input. It's the computer graphic equivalent of throwing a can of paint at the canvas, or painting a few geometric figures; the idea is small, and its translation into the final work is mechanical or random.
Art lies in that region of complexity somewhere between randomness and uniformity.
If the criticism you are receiving is simply about the medium you are using, rather than the forms you are creating within that medium, then that is pure elitism. You should discount that immediately. Any criticism that is not related to what you are actually creating, but to your unorthodox method of creation, should not be considered valid criticism at all.
You have to remember that in the world of art, the value of an artwork is judged by things other than its content. A ridiculously high value is ascribed to an original paining, for instance, even though a faithful replica carries the same information.
In computer graphics, there is no such thing as an original; all copies are equivalent. I suspect that this has a lot to do with why the players in the art world are so disparaging of computer art. You can't do the same kind of wheeling and dealing! A gallery cannot say that it has the original work of some computer graphic artist. A computer file at an surreal price.
(Okay, what you could do is make a one and only print, and then destroy all the digital artifacts that went into it, but I think that digital artists regard those digital artifacts as the real work of art; who wants to destroy their work?)
Suppose you could have a large cluster of small computers to compute things which are highly parallelizable. This cluster should probably be arranged in a sphere to make the computers as close together as possible. The source of computation requests would probably be placed in the centre of the sphere. So the turnaround time of the computers on the surface of the sphere is then bounded by the time needed for light to travel the radius of the sphere twice. To keep the outer computers busy, you need a longer queue of processing requests. Any pointers to papers about this?
I'd like to see an analysis for the breakeven point; for what problems would a sphere of a given radius containing computers of a given speed provide a speedup, such that any larger radius would diminish the return, despite adding to the aggregate computing power?
It could mean, ``migrate to a security platform supported on Linux''. ;)
Come on, you read Ballmer. This is just ``fair compensation'' for copies of your ``intellectual property''.
The computer's guts have to be surrounded by a conductive jacket that is grounded, so that no electromagnetic radiation can escape. The FCC, or similar bodies elsewhere, would not approve of an unshielded case.
;)
So if you have a wooden case, it still needs a layer of shielding, either on the inside our outside. So you might as well just make the case out of sheetmetal and dispense with the wood.
Then there is the weight, and the fact that wood is a good thermal insulator.
I think that cost could be an issue for cases made of a quality hardwood. The whole idea here, to me, is to get an esthetic cabinet made of a finer material; making it out of plywood or MDF kind of defeats the purpose, since these materials are inferior to metal or even plastic. (Yet, people *will* buy particleboard garbage if it has veneer---this is the founding principle behind IKEA, for instance). The cost for cranking out pine, plywood or MDF cases in high volumes is probably not much greater than ordinary cases, but once you get into the better hardwoods, it gets more expensive. Never mind oak, how about a case made of bubinga, wenge and other such hardwoods? Why stop at cases? I'd like a keyboard made of zebrawood, with ebony keycaps, either without labels or labels made using mother-of-pearl inlay.
``For use on * operating systems only'', where * represents free, or whatever other non-functional attribute, is clearly a case of the vendor imposing his will to restrict uses of the software which do not affect anyone else but the user. The vendor is taking away certain freedoms from the user, freedoms which don't encroach on other people's freedoms. So this is a foul restriction in the light of a basic freedom principle, namely that what other people do is their business if it doesn't affect you.
Note that the GNU license doesn't restrict uses of software, only that redistribution of the software, when it occurs, should happen in certain ways which promote the freedom. The license takes away only one freedom: the freedom to impose a reduced freedom on others.
If you want to feed one million people, you have to produce one million meals. If you want to clothe one million people, you have to make one million outfits.
If you want to get one million people to each run a web server, they obviosuly need up to a million computers to run them on and a network. But you only have to give them *ONE* web server program!
Whereas the software-duplication industry claims that no, you have give these people one million programs (which happen to be identical), that each copy is in effectively a new program, a new product of the software industry. Moreover each new such product contributes to the economy. At least this is what apologists like Mundie claim when it suits their anti-free-software agenda. When it comes to the anti-piracy agenda, the spin is different. Then it is readily admitted that there is in fact only one program which is the sole property of the vendor, and the users are merely granted a license to execute one copy of that program at a time. So the users do not in fact own any product, only some limited permission.
Mart, I don't disagree that software can cause economic growth. However, I'm saying that *sales* of *copies of software* are not themselves economic growth.
It's clear to me that the execution of software on a computer can contribute to economic growth whether or not that software is freely redistributable and maintainable by its users.
Now Mundie makes the argument that it's the direct sales of software with a proprietary license which contributes to economic growth, and then he quotes some revenue numbers to back that up. I'm saying that those revenue numbers are simply evidence of a kind of transfer payment, effectively a tax, and not of economic growth.
The people using that software could have made their own copies of it, and could be just as productive by having their computers execute those copies, and so whatever economic benefit there is exists regardless of the transfer payment.
Of course, the common argument is that the software wouldn't exist in the first place if it weren't for the venture capitalists who undertook risks to fund its development, and need to keep the software proprietary to recover their costs.
That's like arguing that housework won't get done if we can't keep slaves.
The value of an Apache binary is its ability to execute. Yes, it certainly is no more difficult to make copies of that apache binary than to make copies of a string of all-zero bits. The actual bits of the binary do not have any value. The program source of course has a lot of value, undoubtedly. It's valuable that there is a single idea called Apache embodied in copies of source code.
When you produce something tangible, the structure of that thing dictates the difficulty of producing more copies of it. For example, a Rolex watch is arguably more demanding to produce than a $5 dollar plastic digital watch, due to the materials, demand for precision, more use of custom parts, and so on. So we say that the Rolex has a greater value.
I also disagree with your naive claim that clothing is easily replicated. If so, why isn't everyone you doing it? I would certainly replicate my clothing if it were possible. Why don't all clothing consumers put in the equipment investment and labor to ``replicate'' their own clothing?
Perhaps you are confusing the ability to crank out a lot of clothing with replication. Mass production is achieved by having a lot of people sweat out each piece of clothing in parallel. If you trace the development of an individual clothing article through the production line, it will be obvious that what is going on is not replication, but construction. The method by which the clothing is assembled has to do with its structure: the procedure for making a shirt differs from the procedure for making a glove. Whereas replicating information is completely blind to the nature or complexity of its structure. The method for replicating information is a function of the source and target representation media, not of what is being copied.
So you see writing this kind of program or that is vaguely similar to sewing this kind of clothing article or that: compiler or editor, glove or shirt. Designing the program is somewhat similar to designing the clothing. But replicating the program, once it is finished---that has no analogy in clothing production! The program is an idea, not a thing. Two copies of the program are really just aliases for the same program, you do not really have two programs! If I state a true sentence twice, do I have two truths?
Didn't Edison simply steal the lightbulb idea from someone else? He also used gruesome public electrocutions of animals to scare people from adopting alternating current. This guy had the sowing of fear, uncertainty and doubt down to an art! No wonder Mundie invokes his name in awe. :)
Didn't you read the article? He makes a highly fallacious argument that free software is bad for the economy, because proprietary software is good for the economy. I made a top-level response to this nonsense elsewhere in this discussion.
So, if free software is bad for the economy, not only is it bad for the users of that software, but for everyone else! So this implies that the writers, and primarily the users of free software can be blamed for contributing to economic problems. Not only are the users parasites and freeloaders, but they contribute negatively!
Hey Mundie, why not just go right out and blame free software users for recent downturns in some sectors of IT?
I suspect that redneck patriotism is at the heart of Mundie's cloudy reasoning, in addition to greed and all that. Free software is un-American because pesky outsiders can connect to American FTP sites and download free software, instead of buying proprietary software. And of course, any worthwhile software, free or otherwise, is American; none of those foreign idjits know what they are doing. So therefore those who give software away are traitors who are robbing the number one country in the world from some of its software taxation income!
Software doesn't actually have any value in and of itself. The companies which mass produce software and charge for it are not driving the economy in any way, they are simply taxing it!
When you sell software within your own country, you are simply redistributing wealth, not generating any. Money flows from the software users into the pockets of the software tycoons (who probably spend and invest a great lot of it abroad). There is no net economic gain in the transaction. Whenever this software-copying industry (let's call it what it is) makes a new CD, they are effectively printing their own money.
What drives the economy is real production of goods: think food, clothing, energy, transportation etc. Software can make the management of production more efficient in many direct and indirect ways, so it contributes to the value production indirectly. Individuals and organizations can be more efficient in certain ways if they have the right software. But it's the surplus created by the real industry which allows the technological priesthood to engage in pleasant intellectual diversions, such as the production of software, and then pretend they are doing some sort of all-important economic activity.
The value provided by software is related to *executing* the software. There is no intrinsic value in the actual ones and zeros which are replicated trivially and at low cost. Executing the software does not cause those ones and zeros to be consumed (unless they are specially contrived ones and zeros, comprising some kind of bullshit license, which can be circumvented, unlike the law of conservation of energy). On the contrary, those ones and zeros can be replicated with a cost that is not only small, but is invariant with the complexity of the software. All that is consumed when software is copied or executed is energy. The fallacious argument that Mundie is making rests on the premise that the ones and zeros in fact have the same kind of intrinsic value as grains of wheat or barrels of oil. The truth is that they only have a value to the ``intellectual property holder'', and they only have that value because some artificial law which entitles only them to make copies for others. Take away that law, and people will continue to write software---that much is clear! Only, according to Mundie, that software will no longer have value, even if its execution continues to provide the same value as ever. What he means is that it will no longer have taxation value to him.
Are you sure these guys are programmers? I put most of a whole company on WinCVS within the last half a year or so. Looking at the /home directory of my CVS server, I see about 70 accounts belonging to users who access CVS over RSH from Windows boxes. I, along with a few others, provide minimal support besides setting up new accounts.
However, I write all my documentation in LaTeX, using encapsulated PostScript for diagrams. This isn't a problem, because I can generate a PDF which is stored in CVS along with the text source files. I do this for software internal documentation as well as for presentation materials (slides).
Binary files are okay in CVS as long as they are derived objects rather than primary objects. What happens during a merge is that you merge the primary objects (LaTeX source files), and regenerate the derived binary object (PDF) from the primary sources and commit the results. However, when the primary objects are non-mergeable (e.g Word documents) you are in trouble. If two people modify the same Word document on separate branches, there is no way to merge other than by hand editing.
With LaTeX, the documentation can be broken into many files which are stitched together with \input directives. This was an advantage because at one point I was working in a small team on the same document. Using multiple files minimizes the amount of back and forth merging that takes place with concurrent development.
I have a few LaTeX macros which can be used to embed CVS keywords like $Id$ in a special way into the documents. The macro actually collects these into a file during latex processing. A special appendix is then added to the output which lists all of the source files and their versions. This is called the ``Bill of Materials'' and tells the reader exactly what versions of the files in CVS correspond to the hard copy.
Here is a good advocacy page you can throw at people who think that word processors are actually suitable tools for intelligent documenting: Word Processors: Inefficient and Stupid.