The open source model lets creative people come up with superior strategies for winning. It's retarded to run around with the mouse and fire if you can use your brains and hack up some code to kick everyone's asses.
Plus isn't it, at least to some extent, the fault of the design of the game protocol in that it facilitates cheating? A well designed protocol would not allow client modifications to give rise to cheats---other than the creation of robot players with superhuman reflexes. Even that could be eliminated; the game server could be equipped with detection heuristics in order to kick suspected robot players off, or handicap them in some way.
I think that people who cry ``cheat'' are just damn whiners lashing out against nerds who are applying ``alternative skills'' to the game.
With Open Source software, there is typically no warranty as to the quality or fitness for a particular purpose. But that's OK because the user is not required to pay for the product and is permitted to inspect it and modify it should the quality or suitability be lacking.
The GNU license permits a seller (who is not necessarily the developer) to offer warranty protection. Which means that if you want someone to blame, you just have to find someone who is willing to sell such warranty protection for a given product.
The Microsoft model doesn't permit the user to inspect the software and make improvements. Nor does it create business model for third party vendors. What I mean is, you could sell warrany protection for Microsoft software but you would be crazy to do so, not having any power to actually resolve an emerging issue.
In other words, there is fairness in the Open Source world. I'm not going to guarantee that this program works, but neither will I twist your arm with a draconian license that doesn't permit copying, withhold the source code from you and charge you good money. If you are going to pay money to me, then, unlike say Microsoft, I'm going to stand behind the software.
It's just a sheet of metal or fibreglass. It doesn't generate heat, and its temperature probably follows that of its surroundings closely. Thus you wouldn't expect it to generate a lot of infra-red energy compared to some other objects, such as living things.
The idea is not to replace the driver's view of the road but rather to augment it. Road signs are already coated with a material which makes them reflect headlights, so they are highly visible already without any help.
Just wait until you can get some generic system that can be retrofitted into any car. It looks like it should be doable. The system components, as described, are a camera mounted behind the car's grille, some processor that can be put anywhere, and some method of projection from the dashboard. It's just a matter of availability of the parts.
Companies don't typically send developers to man trade show booths; it sends sales and marketing people. So no kidding they are going to have a hard time with tough questions, and probably become annoyed at being asked the same thing all day long to which they don't have an answer to! These are the wrong people to be giving suggestions about opening hardware specifications, releasting code or supporting another operating system. They probably haven't even seen a spec, or source code, and don't understand what it means to support different operating systems. Give these people a break!
The techies are back in the office, fixing bugs, and generally prepared to fight fires if something goes wrong with a demo. These are the people who will probably push their product management toward Linux support.
Sheet music is not to a performance what source code is to binary code.
The relationship between sheet music and a musical performance is more like the relationship between program text and the performance of a program, but even that is a bit of a strech.
The performance of sheet music has as its ingredients the information in the sheet music itself, plus the artist's interpretation which endow the performance with meaningful nuances.
The performance of a program, likewise, is derived from the program's code and whatever input goes into it, which may include static data, real-time inputs, etc.
Not all musical performance comes from notation; just like not all data is the output of a program.
The relationship between source and binary code is more like the relationship between a musical score and some lower-level representation of the musical score, like a piano roll. A piano roll is just like machine language: it has binary words consisting of punched holes. These trigger a ``control unit'' which drives the hammers that strike strings. Admittedly, it's a very horizontal encoding.:)
It would be reasonable to distribute piano rolls under a GPL-like license requiring that the sheet music be available to the pianist. But a key motivation for this isn't there: namely the need to modify. Neither form allows for easy modification, and few players are interested in rewriting a piece. There is a pragmatic need to be able to modify programs to suit changing requirements which is doesn't apply to expressive works.
I challenge the notion that requiring a company to open the source code is the same as the taking of property.
Instead, it is merely the removal of copyright restrictions. Actually, it's not even that, because they copyrights can remain. The only difference is that the status of the work would change from unpublished to published. Thus, arguably, no rights would be taken from Microsoft. Copyright law still protects the authors of published works---books, music, art, etc. You don't see too many of these people worried that their copyrighted works are published.
The rights covered under copyright don't have a direct basis in the U.S. constitution, do they? Property is something you can hold; when you take property from someone, it means that some material thing is taken. Making a copy of something doesn't leave the owner with anything less.
People should learn to distinguish between ``property'' and ``copyright''.
A case could be made that Microsoft has taken more than enough money from people to justify handing over a copy of their source code to these licensees. It could also be argued that so many people are dependent on Microsoft's buggy products that not having access to the source code is dampening productivity and harming the economy.
It should be made illegal for an individual or organization to make another individual or organization depend on software that cannot easily be modified. There needs to be a trade law to ban the sale of software without accompanying source code. If someone wishes to keep software proprietary, the only way to do that should be to keep it unpublished in either form---in other words, don't give a copy to anyone outside of the organization, not in binary or source form.
Or how about this: copyright laws should be changed to accomodate the notion that if the binary code of some program is published, then the source code is considered published, and any licensing terms applying to the binary code should automatically apply to all other forms in which that work appears, including the source code. Thus if a company's source code leaked out, it would automatically be considered licensed to all existing license holders who previously received binaries only.
The purpose of writing in a high level language and translating to machine language is to enable complex software to be developed and maintained, and to be executed efficiently. High level languages were designed to make it convenient to program computers and advance the state of software development, not to gouge customers. The ability to do that is just an accidental side effect which needs to be stomped out.
Whatever representation of the program that is produced by the developers *is* that program. If I write some program in C and call it Foo, and then give you a compiled version, I am not giving you Foo. I'm giving you a shadow cast by Foo in the light of a particular compiler.
People copy copyrighted material from CD's to hard disks all the time. It's called ``software installation''. Also, back in the days when software was shipped on floppies, it was acceptable practice to make backup floppies.
Copies that are made for personal convenience or backup purposes don't amount to copyright infringement.
The DJ already has legal master copies and is allowed to play them to the clients, so what does it matter by what means the music makes its way to the speakers?
What's surprising to me is that this wasn't previously allowed.
Somewhere out there is a company collecting the best part of the GNU/Linux work, adding their own code with intent to repackage. This is what the open source movement should be afraid of.
In today's anti-piracy climate, woe to whoever is caught! The horribly bad publicity alone arising out of discovery wouldn't be worth it.
Let's look at this closely: suppose that someone does take GNU code and incorporates it into a proprietary product. Does a truly cutting edge company need to steal code? You are playing catch-up if you need to steal.
Secondly, what if someone does that? At best, they will buy themselves reduced development time on some isolated project. The real benefits of the code, namely openness, will be lost. People using the main development stream will get the latest features and bugfixes, and the pirates will be locked into playing catch-up. They can't openly advertize that they have stolen code, so if the code really has a great reputation, they can't boast of it. They can't actively participate in the development process.
Thirdly, no serious company is going to risk it. I know that in my company, nobody would even want to hear of such as thing as GPL'ed code being incorporated into our products. If we use free software, we evaluate the licenses carefully. It would be foolhardy to do otherwise.
There is plenty of useful code out there which has licenses that are more permissive than the GPL. Particularly things that provide some generic, low-level functionality such as, say, compression.
I think that if Stallman were here, he would say that songs are different from computer software and so that the same thinking doesn't apply.
Songs are not source code that is translated into machine code. We generally do not have access to the ``source'' for the music, only to the performance, which is captured by recording the sound waves.
The GPL is special in its requirements related to the relationship between the source code and compiled code; in other respects it is a license that permits free distribution of something.
If it is the free distribution that you object to, then it's meaningless to have a debate about the relative merits of various freeware licenses, all of which permit free redistribution of the source.
Anyway, the GPL protects primarily the freedom of _users_, not the freedoms of those who want to profit by making software proprietary. Stallman has argued that this is not really freedom, but the exercise of power. (As in power == control over things that affect others, freedom == control over things that affect yourself).
This is a little off topic, but I just wanted to mention a decent free windows client solution I have found: the combination of ssh compiled under Gnu-Win32 together with the Gnu-Win32 port of rxvt.
F-secure is garbage. I tried it for 30 days and decided not to give it a second look; it doesn't handle color properly, nor resizing. ssh + rxvt handles resizing properly, so I can be typing in vi on the remote machine, change the size of the local window and the remote editor is notified. Plus the color support is there so I can edit code on a remote machine using vim with all the syntax coloring crap working properly.
To boot, rxvt copy and paste behaves in the standrad way: highlighting automatically copies, middle button pastes!
SecureCRT looks a lot better than F-secure (color, resizing works), but it's the same old 30 day crippleware story. (Plus it integrates everything into one program, which is stupid. Why not have a separate terminal emulator and ssh client instead of making a monolithic thing that does the terminal emulation?)
One reason may be latency. If your data link rate is R bits per second and you gather N bits for encryption, you are introducing N * R seconds of latency. If you can clock out individual bits as they come in, you reduce the latency.
Another reason may be the saving of space. Think of remote login connections. The user types one character at a time. But most block ciphers operate on at least eight bytes at a time. It would be wasteful to send eight bytes for one keystroke (assuming we ignore the sad fact that over TCP, each keystroke already turns to 41 bytes; Nagle helps with this, but only if you type faster than the network delay. Some programs, notably SSH disable Nagle). In any case, by using a stream cipher, or a block cipher operated as a stream cipher (for example, using CFB mode) you can shift out one byte for each keystroke down to the transport layer or datalink or what have you.
Using one fast adapter instead of four slower ones woudln't help because you would still fail to take advantage of the other processors. The interrupt servicing would be serialized to one processor at a time.
By binding each of four cards to a different processor, you allow up to four interrupt service routines to proceed concurrently. The question is whether the service routines can get into the stack without getting in each other's way.
In Linux 2.0 and before, what happens is that each adapter, when it receives a packet, calls a routine which atomically enqueues it into a global queue. What pushes packets from the global queue is ``bottom half processing'' which is sort of a virtual thread that does its job when returning from system calls or from interrupts.
I don't have a complete picture of the 2.2 architecture (despite successfully porting a network driver to it from 2.0!) but I think that the bottom half stuff is still emulated in a coarse way. Historically, a lot of code depends on bottom half processing to be atomic with respect to itself and you can't change that overnight.
The actual pushing of packets from the global receive queue into the upper network layers is done as part of this bottom half processing. So is the pushing of backlogged transmit data down to the network drivers. If only one processor can do this processing at a time, there is an obvious reduction in concurrency. An obvious extension would be to let all of the processors do bottom half processing concurrently. In the case of network input, for instance, all the processors could enter into a loop in which they are yanking received packets from the global queue and driving the higher level TCP/IP code concurrently.
Here are some of the assumptions that you could make when programming for 2.0 kernels and earlier:
- bottom-half processing is atomic with respect to itself. That is, it can't be interrupted and re-initiated. It can, however, be interrupted to service lower level interrupts.
- bottom-half processing happens only at interrupt level one. Thus by incrementing the interrupt level, you could protect a section of code against being re-entered by bottom-half processing. The start_bh_atomic() and end_bh_atomic() macros would just do this intr_count++ and intr_count--. Thus synchronizing between system call (process context) code and bottom half callback can be done trivially, and without touching the processor interrupt mask at all.
- disabling interrupts protects you against everything.
The real challenge has been not just in going from coarse grained to fine grained locks, but in reworking the assumptions.
For backward compatibility, the old mechanisms still exist in 2.2. For example, you can still use sti() to disable interrupts, and can continue to pretend that this works as before. Under SMP however, it is emulated in a rather gross way! If you want the real interrupt disable instruction, you have to use __sti(), which only disables interrupts on the current processor, not guaranteeing complete atomicity.
Saying that the TCP/IP stack is ``single threaded'' is completely misleading. The TCP/IP stack in Linux isn't threaded at all. It is not a process. It is just a bunch of code operating on data that is shared among processes/threads and interrupt service routines. Any process in the system may enter the TCP/IP code, as may any interrupt on any processor. The Mindcraft cluelessness about how the kernel works takes even more away from what little credibility they have left.
To say that the Linux stack is single-threaded implies that it has an internal thread which does all the work. Obviously, this is far from the case.
In _The Psychology of Computer Programming_(*), Gerald Weinberg wrote a story about a programmer who was flown to Detroit to help debug a program that was in trouble. The programmer worked with the team of programmers who had developed the program, and after several days he concluded that the situation was hopeless.
On the flight home, he mulled over the last few days and realized the true problem. By the end of the flight, he had outlined the necessary code. He tested it for several days and was about to return to Detroit when he got a telegram saying the project had been cancelled because the program was impossible to write. He headed back to Detroit anyway and convinced the executives that the project could be completed.
He then had to convince the project's original programmers. They listened to his presentation, and when he'd finished, the creator of the old system asked,
"And how long does your program take?"
"That varies, but about ten seconds per input."
"Aha! But my program takes only one second per input." The veteran leaned back, satisfied that he'd stumped the upstart programmer. The other programmers seemed to agree, but the new programmer wasn't intimidated.
"Yes, but your program doesn't work. If mine doesn't have to work, I can make it run instantly and take up no memory. "
Moral of the story: correctness first, then speed. How fast would NT be if they fixed it?;)
To answer your question, whoever moderated it up must have been the one with the reading comprehension plug-in.
Re-reading my posting again, it's painfully clear that I wrote about moderated newsgroups, not about self-moderation methods like kill-files.
Kill-files work well, but are not perfect. Some of the most annoying Usenet pests are work hard at find creative ways to keep escaping kill filters. They change identities, subjects, styles. So your file grows longer and longer. I've seen some who start by being completely annoying in a random way, but later adapt to the style of a newsgroup and start being specifically annoying within the subject of discourse.
In the past, I have resorted to having to killfile by news server, which was not a decision I enjoyed making. It is very effective at filtering out annoying individuals, because they can't change news servers as easily or frequently as the characteristics of their postings.
Another problem is that kill fitering is done on the client side. For any sort of filtering to take place, your reader has to download at least the headers. But filtering out some crap requires message bodies as well. This is less of a problem these days because connections have gotten faster, but not for everybody.
Also, while on the topic, I don't believe that litigation is the answer: I said that ``it's fine'' in response to the earlier postings that were crying censorship. The gag order, however extreme, is not a form of censorship, in my view. Posting to Usenet is just a form of public expression. People get dragged into court for speaking and writing in traditional forums; there is no reason to expect to be able to do anything you want in Usenet and harass people with perfect impunity. I hope that this incident sends out a message to the kooks and harassers that they are not beyond the reach of the law.
PDP emulation---screw space wars, run V7 UNIX!
on
Spacewar! Lives Again
·
· Score: 3
I played with this a couple of years ago. There was (probably still is) a PDP-11 emulator you could download from ftp.dec.com. With the provided disk images, you could run V7 UNIX. I played with it for a while; I was able to log in, wrote a little C program using ed, and then compile and run it. Here, I think I found the link! (ftp://ftp.digital.com/pub/DEC/sim/).
In my opinion, mailing-lists and www-boards suck donkey poo-poo compared to Usenet.
Slashdot proves that building a moderation system is easy within the confines of a single web site where everyone is authenticated, and the information isn't distributed across a wide area. You could do the same thing with a single private NNTP server with authenticated access, and kill files.
Usenet is a world-wide distributed system, with many points of entry and countless users who aren't tracked in any way. The problems to be solved there are entirely on a different plane.
IMHO, what Usenet needs is a protocol for sharing killfile information among like-minded individuals. Killfiles are far better than Slashdot-type moderation because they are content sensitive, and can be made quite specific, like ignoring a particuliar user, or even news server. Scoring newsreaders can assign a score to each article based on multiple filter criteria, similar to slashdot scores. Killfiles and scoring scale nicely, because they are processed at the client side. What you need is to be able to share ``kill packets'' with other users. Instead of having one huge moderation system, you have a disconnected model. There is no need for there to be one monolithic moderation database which appears identical to everyone, so it would be a waste of resources to try to construct one.
Slashdot doesn't compare to Usenet. I find that you can't have meaningful threads of conversation, and then sense of community just isn't here! Topics keep being thrown in, then some fast exchanges ensue and die out in favor of the next topic. Also, the graphically-intensive layout sucks, and you have little choice in how it's presented, since there is no protocol here other than HTML. Also, Slashdot can't even be viewed properly unless you use non-free software like Netscape or Internet explorer. Last time I tried Mozilla, it blew up on Slashdot. Maybe the latest milestone does a better job, who knows! On the other hand, Usenet participation requires only free software, like tin, trn or slrn.
Also I find that the Usenet technical forums tend to provide very good quality answers (if you are willing to sift through the rubbish a little bit). From time to time you see postings from people like Dennis Ritchie, Chris Torek, Torvalds, Bjarne Stroustrup, Andrew Koenig, Doug Smith (of ACE fame) and many others. Yes, these guys are on Usenet, not on some web bulletin board. And they use their real names, not some 3l33t pseudonyms.
If you try, you can find far higher calibre discussions on Usenet than in Slashdot. The most interesting aspect of Slashdot are the links to outside stories. I know people that don't even bother reading the replies to a story, and just follow the links from here on out.
The restraining order is not for all of Usenet but for a specific newsgroup. The individual's freedom of speech is therefore not curtailed.
Postings directed to a particular newsgroup may not be targetted at a specific individual, but they are targetted at a community of people formed by the newsgroup's ``regulars''. It's reasonable for these people to want some sort of remedy for someone who is an utter nuisance.
In recent years, groups of individuals have emerged on Usenet whose only intent is to harass. They crosspost on purpose between completely unrelated newsgroups. When someone trims followups, they put them back. They fill their postings with tons of garbage, ASCII graphic crud and whatnot. Clearly, when your only aim is to disturb rational conversation, you aren't expressing your freedom of speech, you are abusing your freedom to curtail that of others.
There are no adequate means of moderation in Usenet (as there is in slashdot), so turning to the courts may be the only way to get peace.
Someone mentioned that there are moderated newsgroups; how little this individual knows how Usenet really works!
First of all, the moderation can be bypassed; you can still post directly to a moderated newsgroup, even though this is obviously highly frowned upon. I have done it once or twice in the past when the moderator's address wouldn't work for me, due to broken software or whatever. Even though there was nothing wrong with my messages---they were the sort that would be passed by the moderator---I received a slap-on-the wrist e-mail not to do that again.;)
Secondly, newsgroup moderation works by filtering postings through the mailbox of some tireless, tolerant individual who has to sift through everything and decide what gets posted. Thus harassment and spam is simply hidden away from the public and suffered by the moderator.
Thirdly, moderated newsgroups tend to be not nearly as lively as their unmoderated counterparts. For example, comp.lang.c.moderated tends to be dead compared to comp.lang.c.
Ultimately, Usenet moderation (as we know it) is not the answer.
Is here. Vernon Reid plays guitar on the most wanted song. Didn't he used to be with a group called Living Color? Pretty demented pseudo-shredder, if I recall.;)
CS degree and fifteen years experience and can't figure out RedHat Linux? Gotta be kidding! Children who aren't even that many years old are running it, changing screen resolution, reading and writing floppies, etc.
Four years ago, I tried installing linux on my machine.
Five years ago, I was doing contract programming for Linux at an firm that was using it as a basis for taking their information business to the web. They were also using it to back up the hard drives of Windows machines on the WFWG network, with the help of early versions of Samba.
I first started using Linux a year or so before that. I knew goofs who were capable of getting it running back in 1993. You must have had a broken distro.
There were already halfway decent installs four years ago. I have kicking around somewhere a bunch of 1995 InfoMagic CD-ROMS with Slackware. From what I remember, the installation was darn easy. That was four years ago, so there!;)
And of course, people were able to get it running as far back as 1991.;)
I can't follow the logic. Okay, I write some software and only I have the source code. I can't manage to support it well, yet people who don't have the source code can do a better job? In what universe?
Like the man said, support is basically limited to training and workarounds. Without access to the code, if an issue arises, all you *can* do is work around it. Some of these third parties are simply good at providing workarounds.
If I'm wrong, show me one service pack, for any version of Windows, that didn't come from Microsoft.
Slashdot Mirror
The open source model lets creative people come up with superior strategies for winning. It's retarded to run around with the mouse and fire if you can use your brains and hack up some code to kick everyone's asses.
Plus isn't it, at least to some extent, the fault of the design of the game protocol in that it facilitates cheating? A well designed protocol would not allow client modifications to give rise to cheats---other than the creation of robot players with superhuman reflexes. Even that could be eliminated; the game server could be equipped with detection heuristics in order to kick suspected robot players off, or handicap them in some way.
I think that people who cry ``cheat'' are just damn whiners lashing out against nerds who are applying ``alternative skills'' to the game.
With Open Source software, there is typically no warranty as to the quality or fitness for a particular purpose. But that's OK because the user is not required to pay for the product and is permitted to inspect it and modify it should the quality or suitability be lacking.
The GNU license permits a seller (who is not necessarily the developer) to offer warranty protection. Which means that if you want someone to blame, you just have to find someone who is willing to sell such warranty protection for a given product.
The Microsoft model doesn't permit the user to inspect the software and make improvements. Nor does it create business model for third party vendors. What I mean is, you could sell warrany protection for Microsoft software but you would be crazy to do so, not having any power to actually resolve an emerging issue.
In other words, there is fairness in the Open Source world. I'm not going to guarantee that this program works, but neither will I twist your arm with a draconian license that doesn't permit copying, withhold the source code from you and charge you good money. If you are going to pay money to me, then, unlike say Microsoft, I'm going to stand behind the software.
Maker of amplifiers for playing hard rock and shred music. Much more significant than some scribbler.
;)
echo "blah" > #temporary_file#
mv #temporary_file# existing_file
There is your atomic supersede. It's in the atomic rename operation..
It's just a sheet of metal or fibreglass. It doesn't generate heat, and its temperature probably follows that of its surroundings closely. Thus you wouldn't expect it to generate a lot of infra-red energy compared to some other objects, such as living things.
The idea is not to replace the driver's view of the road but rather to augment it. Road signs are already coated with a material which makes them reflect headlights, so they are highly visible already without any help.
Just wait until you can get some generic system that can be retrofitted into any car. It looks like it should be doable. The system components, as described, are a camera mounted behind the car's grille, some processor that can be put anywhere, and some method of projection from the dashboard. It's just a matter of availability of the parts.
Companies don't typically send developers to man trade show booths; it sends sales and marketing people. So no kidding they are going to have a hard time with tough questions, and probably become annoyed at being asked the same thing all day long to which they don't have an answer to! These are the wrong people to be giving suggestions about opening hardware specifications, releasting code or supporting another operating system. They probably haven't even seen a spec, or source code, and don't understand what it means to support different operating systems. Give these people a break!
The techies are back in the office, fixing bugs, and generally prepared to fight fires if something goes wrong with a demo. These are the people who will probably push their product management toward Linux support.
Sheet music is not to a performance what source code is to binary code.
:)
The relationship between sheet music and a musical performance is more like the relationship between program text and the performance of a program, but even that is a bit of a strech.
The performance of sheet music has as its ingredients the information in the sheet music itself, plus the artist's interpretation which endow the performance with meaningful nuances.
The performance of a program, likewise, is derived from the program's code and whatever input goes into it, which may include static data, real-time inputs, etc.
Not all musical performance comes from notation; just like not all data is the output of a program.
The relationship between source and binary code is more like the relationship between a musical score and some lower-level representation of the musical score, like a piano roll. A piano roll is just like machine language: it has binary words consisting of punched holes. These trigger a ``control unit'' which drives the hammers that strike strings. Admittedly, it's a very horizontal encoding.
It would be reasonable to distribute piano rolls under a GPL-like license requiring that the sheet music be available to the pianist. But a key motivation for this isn't there: namely the need to modify. Neither form allows for easy modification, and few players are interested in rewriting a piece. There is a pragmatic need to be able to modify programs to suit changing requirements which is doesn't apply to expressive works.
I challenge the notion that requiring a company to open the source code is the same as the taking of property.
Instead, it is merely the removal of copyright restrictions. Actually, it's not even that, because they copyrights can remain. The only difference is that the status of the work would change from unpublished to published. Thus, arguably, no rights would be taken from Microsoft.
Copyright law still protects the authors of published works---books, music, art, etc. You don't see too many of these people worried that their copyrighted works are published.
The rights covered under copyright don't have a direct basis in the U.S. constitution, do they? Property is something you can hold; when you take property from someone, it means that some material thing is taken. Making a copy of something doesn't leave the owner with anything less.
People should learn to distinguish between ``property'' and ``copyright''.
A case could be made that Microsoft has taken more than enough money from people to justify handing over a copy of their source code to these licensees. It could also be argued that so many people are dependent on Microsoft's buggy products that not having access to the source code is dampening productivity and harming the economy.
It should be made illegal for an individual or organization to make another individual or organization depend on software that cannot easily be modified. There needs to be a trade law to ban the sale of software without accompanying source code. If someone wishes to keep software proprietary, the only way to do that should be to keep it unpublished in either form---in other words, don't give a copy to anyone outside of the organization, not in binary or source form.
Or how about this: copyright laws should be changed to accomodate the notion that if the binary code of some program is published, then the source code is considered published, and any licensing terms applying to the binary code should automatically apply to all other forms in which that work appears, including the source code. Thus if a company's source code leaked out, it would automatically be considered licensed to all existing license holders who previously received binaries only.
The purpose of writing in a high level language and translating to machine language is to enable complex software to be developed and maintained, and to be executed efficiently. High level languages were designed to make it convenient to program computers and advance the state of software development, not to gouge customers. The ability to do that is just an accidental side effect which needs to be stomped out.
Whatever representation of the program that is produced by the developers *is* that program. If I write some program in C and call it Foo, and then give you a compiled version, I am not giving you Foo. I'm giving you a shadow cast by Foo in the light of a particular compiler.
People copy copyrighted material from CD's to hard disks all the time. It's called ``software installation''. Also, back in the days when software was shipped on floppies, it was acceptable practice to make backup floppies.
Copies that are made for personal convenience or backup purposes don't amount to copyright infringement.
The DJ already has legal master copies and is allowed to play them to the clients, so what does it matter by what means the music makes its way to the speakers?
What's surprising to me is that this wasn't previously allowed.
Somewhere out there is a company collecting the best part of the GNU/Linux work, adding their own code with intent to repackage. This is what the open source movement should be afraid of.
In today's anti-piracy climate, woe to whoever is caught! The horribly bad publicity alone arising out of discovery wouldn't be worth it.
Let's look at this closely: suppose that someone does take GNU code and incorporates it into a proprietary product. Does a truly cutting edge company need to steal code? You are playing catch-up if you need to steal.
Secondly, what if someone does that? At best, they will buy themselves reduced development time on some isolated project. The real benefits of the code, namely openness, will be lost. People using the main development stream will get the latest features and bugfixes, and the pirates will be locked into playing catch-up. They can't openly advertize that they have stolen code, so if the code really has a great reputation, they can't boast of it. They can't actively participate in the development process.
Thirdly, no serious company is going to risk it. I know that in my company, nobody would even want to hear of such as thing as GPL'ed code being incorporated into our products. If we use free software, we evaluate the licenses carefully. It would be foolhardy to do otherwise.
There is plenty of useful code out there which has licenses that are more permissive than the GPL. Particularly things that provide some generic, low-level functionality such as, say, compression.
I think that if Stallman were here, he would say that songs are different from computer software and so that the same thinking doesn't apply.
Songs are not source code that is translated into machine code. We generally do not have access to the ``source'' for the music, only to the performance, which is captured by recording the sound waves.
The GPL is special in its requirements related to the relationship between the source code and compiled code; in other respects it is a license that permits free distribution of something.
If it is the free distribution that you object to, then it's meaningless to have a debate about the relative merits of various freeware licenses, all of which permit free redistribution of the source.
Anyway, the GPL protects primarily the freedom of _users_, not the freedoms of those who want to profit by making software proprietary. Stallman has argued that this is not really freedom, but the exercise of power. (As in power == control over things that affect others, freedom == control over things that affect yourself).
This is a little off topic, but I just wanted to mention a decent free windows client solution I have found: the combination of ssh compiled under Gnu-Win32 together with the Gnu-Win32 port of rxvt.
F-secure is garbage. I tried it for 30 days and decided not to give it a second look; it doesn't handle color properly, nor resizing. ssh + rxvt handles resizing properly, so I can be typing in vi on the remote machine, change the size of the local window and the remote editor is notified. Plus the color support is there so I can edit code on a remote machine using vim with all the syntax coloring crap working properly.
To boot, rxvt copy and paste behaves in the standrad way: highlighting automatically copies, middle button pastes!
SecureCRT looks a lot better than F-secure (color, resizing works), but it's the same old 30 day crippleware story. (Plus it integrates everything into one program, which is stupid. Why not have a separate terminal emulator and ssh client instead of making a monolithic thing that does the terminal emulation?)
One reason may be latency. If your data link rate is R bits per second and you gather N bits for encryption, you are introducing N * R seconds of latency. If you can clock out individual bits as they come in, you reduce the latency.
Another reason may be the saving of space. Think of remote login connections. The user types one character at a time. But most block ciphers operate on at least eight bytes at a time. It would be wasteful to send eight bytes for one keystroke (assuming we ignore the sad fact that over TCP, each keystroke already turns to 41 bytes; Nagle helps with this, but only if you type faster than the network delay. Some programs, notably SSH disable Nagle). In any case, by using a stream cipher, or a block cipher operated as a stream cipher (for example, using CFB mode) you can shift out one byte for each keystroke down to the transport layer or datalink or what have you.
Using one fast adapter instead of four slower ones woudln't help because you would still fail to take advantage of the other processors. The interrupt servicing would be serialized to one processor at a time.
By binding each of four cards to a different processor, you allow up to four interrupt service routines to proceed concurrently. The question is whether the service routines can get into the stack without getting in each other's way.
In Linux 2.0 and before, what happens is that each adapter, when it receives a packet, calls a routine which atomically enqueues it into a global queue. What pushes packets from the global queue is ``bottom half processing'' which is sort of a virtual thread that does its job when returning from system calls or from interrupts.
I don't have a complete picture of the 2.2 architecture (despite successfully porting a network driver to it from 2.0!) but I think that the bottom half stuff is still emulated in a coarse way. Historically, a lot of code depends on bottom half processing to be atomic with respect to itself and you can't change that overnight.
The actual pushing of packets from the global receive queue into the upper network layers is done as part of this bottom half processing. So is the pushing of backlogged transmit data down to the network drivers. If only one processor can do this processing at a time, there is an obvious reduction in concurrency. An obvious extension would be to let all of the processors do bottom half processing concurrently. In the case of network input, for instance, all the processors could enter into a loop in which they are yanking received packets from the global queue and driving the higher level TCP/IP code concurrently.
Here are some of the assumptions that you could make when programming for 2.0 kernels and earlier:
- bottom-half processing is atomic with respect to itself. That is, it can't be interrupted and re-initiated. It can, however, be interrupted to service lower level interrupts.
- bottom-half processing happens only at interrupt level one. Thus by incrementing the interrupt level, you could protect a section of code against being re-entered by bottom-half processing. The start_bh_atomic() and end_bh_atomic() macros would just do this intr_count++ and intr_count--. Thus synchronizing between system call (process context) code and bottom half callback can be done trivially, and without touching the processor interrupt mask at all.
- disabling interrupts protects you against everything.
The real challenge has been not just in going from coarse grained to fine grained locks, but in reworking the assumptions.
For backward compatibility, the old mechanisms still exist in 2.2. For example, you can still use sti() to disable interrupts, and can continue to pretend that this works as before. Under SMP however, it is emulated in a rather gross way! If you want the real interrupt disable instruction, you have to use __sti(), which only disables interrupts on the current processor, not guaranteeing complete atomicity.
Saying that the TCP/IP stack is ``single threaded'' is completely misleading. The TCP/IP stack in Linux isn't threaded at all. It is not a process. It is just a bunch of code operating on data that is shared among processes/threads and interrupt service routines. Any process in the system may enter the TCP/IP code, as may any interrupt on any processor. The Mindcraft cluelessness about how the kernel works takes even more away from what little credibility they have left.
To say that the Linux stack is single-threaded implies that it has an internal thread which does all the work. Obviously, this is far from the case.
In _The Psychology of Computer Programming_(*), Gerald Weinberg wrote a story about a programmer who was flown to Detroit to help debug a program that was in trouble. The programmer worked with the team of programmers who had developed the program, and after several days he concluded that the situation was hopeless.
;)
On the flight home, he mulled over the last few days and realized the true problem. By the end of the flight, he had outlined the necessary code. He tested it for several days and was about to return to Detroit when he got a telegram saying the project had been cancelled because the program was impossible to write. He headed back to Detroit anyway and convinced the executives that the project could be completed.
He then had to convince the project's original programmers. They listened to his presentation, and when he'd finished, the creator of the old system asked,
"And how long does your program take?"
"That varies, but about ten seconds per input."
"Aha! But my program takes only one second per input." The veteran leaned back, satisfied that he'd stumped the upstart programmer. The other programmers seemed to agree, but the new programmer wasn't intimidated.
"Yes, but your program doesn't work. If mine doesn't have to work, I can make it run instantly and take up no memory. "
Moral of the story: correctness first, then speed.
How fast would NT be if they fixed it?
To answer your question, whoever moderated it up must have been the one with the reading comprehension plug-in.
Re-reading my posting again, it's painfully clear that I wrote about moderated newsgroups, not about self-moderation methods like kill-files.
Kill-files work well, but are not perfect. Some of the most annoying Usenet pests are work hard at find creative ways to keep escaping kill filters. They change identities, subjects, styles. So your file grows longer and longer. I've seen some who start by being completely annoying in a random way, but later adapt to the style of a newsgroup and start being specifically annoying within the subject of discourse.
In the past, I have resorted to having to killfile by news server, which was not a decision I enjoyed making. It is very effective at filtering out annoying individuals, because they can't change news servers as easily or frequently as the characteristics of their postings.
Another problem is that kill fitering is done on the client side. For any sort of filtering to take place, your reader has to download at least the headers. But filtering out some crap requires message bodies as well. This is less of a problem these days because connections have gotten faster, but not for everybody.
Also, while on the topic, I don't believe that litigation is the answer: I said that ``it's fine'' in response to the earlier postings that were crying censorship. The gag order, however extreme, is not a form of censorship, in my view. Posting to Usenet is just a form of public expression. People get dragged into court for speaking and writing in traditional forums; there is no reason to expect to be able to do anything you want in Usenet and harass people with perfect impunity. I hope that this incident sends out a message to the kooks and harassers that they are not beyond the reach of the law.
I played with this a couple of years ago. There was (probably still is) a PDP-11 emulator you could download from ftp.dec.com. With the provided disk images, you could run V7 UNIX. I played with it for a while; I was able to log in, wrote a little C program using ed, and then compile and run it. Here, I think I found the link! (ftp://ftp.digital.com/pub/DEC/sim/).
In my opinion, mailing-lists and www-boards suck donkey poo-poo compared to Usenet.
Slashdot proves that building a moderation system is easy within the confines of a single web site where everyone is authenticated, and the information isn't distributed across a wide area. You could do the same thing with a single private NNTP server with authenticated access, and kill files.
Usenet is a world-wide distributed system, with many points of entry and countless users who aren't tracked in any way. The problems to be solved there are entirely on a different plane.
IMHO, what Usenet needs is a protocol for sharing killfile information among like-minded individuals. Killfiles are far better than Slashdot-type moderation because they are content sensitive, and can be made quite specific, like ignoring a particuliar user, or even news server. Scoring newsreaders can assign a score to each article based on multiple filter criteria, similar to slashdot scores. Killfiles and scoring scale nicely, because they are processed at the client side. What you need is to be able to share ``kill packets'' with other users. Instead of having one huge moderation system, you have a disconnected model. There is no need for there to be one monolithic moderation database which appears identical to everyone, so it would be a waste of resources to try to construct one.
Slashdot doesn't compare to Usenet. I find that you can't have meaningful threads of conversation, and then sense of community just isn't here! Topics keep being thrown in, then some fast exchanges ensue and die out in favor of the next topic. Also, the graphically-intensive layout sucks, and you have little choice in how it's presented, since there is no protocol here other than HTML. Also, Slashdot can't even be viewed properly unless you use non-free software like Netscape or Internet explorer. Last time I tried Mozilla, it blew up on Slashdot. Maybe the latest milestone does a better job, who knows! On the other hand, Usenet participation requires only free software, like tin, trn or slrn.
Also I find that the Usenet technical forums tend to provide very good quality answers (if you are willing to sift through the rubbish a little bit). From time to time you see postings from people like Dennis Ritchie, Chris Torek, Torvalds, Bjarne Stroustrup, Andrew Koenig, Doug Smith (of ACE fame) and many others. Yes, these guys are on Usenet, not on some web bulletin board. And they use their real names, not some 3l33t pseudonyms.
If you try, you can find far higher calibre discussions on Usenet than in Slashdot. The most interesting aspect of Slashdot are the links to outside stories. I know people that don't even bother reading the replies to a story, and just follow the links from here on out.
The restraining order is not for all of Usenet but for a specific newsgroup. The individual's freedom of speech is therefore not curtailed.
;)
Postings directed to a particular newsgroup may not be targetted at a specific individual, but they are targetted at a community of people formed by the newsgroup's ``regulars''. It's reasonable for these people to want some sort of remedy for someone who is an utter nuisance.
In recent years, groups of individuals have emerged on Usenet whose only intent is to harass. They crosspost on purpose between completely unrelated newsgroups. When someone trims followups, they put them back. They fill their postings with tons of garbage, ASCII graphic crud and whatnot. Clearly, when your only aim is to disturb rational conversation, you aren't expressing your freedom of speech, you are abusing your freedom to curtail that of others.
There are no adequate means of moderation in Usenet (as there is in slashdot), so turning to the courts may be the only way to get peace.
Someone mentioned that there are moderated newsgroups; how little this individual knows how Usenet really works!
First of all, the moderation can be bypassed; you can still post directly to a moderated newsgroup, even though this is obviously highly frowned upon. I have done it once or twice in the past when the moderator's address wouldn't work for me, due to broken software or whatever. Even though there was nothing wrong with my messages---they were the sort that would be passed by the moderator---I received a slap-on-the wrist e-mail not to do that again.
Secondly, newsgroup moderation works by filtering postings through the mailbox of some tireless, tolerant individual who has to sift through everything and decide what gets posted. Thus harassment and spam is simply hidden away from the public and suffered by the moderator.
Thirdly, moderated newsgroups tend to be not nearly as lively as their unmoderated counterparts. For example, comp.lang.c.moderated tends to be dead compared to comp.lang.c.
Ultimately, Usenet moderation (as we know it) is not the answer.
Is here. Vernon Reid plays guitar on the most wanted song. Didn't he used to be with a group called Living Color? Pretty demented pseudo-shredder, if I recall. ;)
CS degree and fifteen years experience and can't figure out RedHat Linux? Gotta be kidding! Children who aren't even that many years old are running it, changing screen resolution, reading and writing floppies, etc.
Four years ago, I tried installing linux on my machine.
;)
;)
Five years ago, I was doing contract programming for Linux at an firm that was using it as a basis for taking their information business to the web. They were also using it to back up the hard drives of Windows machines on the WFWG network, with the help of early versions of Samba.
I first started using Linux a year or so before that. I knew goofs who were capable of getting it running back in 1993. You must have had a broken distro.
There were already halfway decent installs four years ago. I have kicking around somewhere a bunch of 1995 InfoMagic CD-ROMS with Slackware. From what I remember, the installation was darn easy. That was four years ago, so there!
And of course, people were able to get it running as far back as 1991.
Windows'', how can third parties be any better?
I can't follow the logic. Okay, I write some software and only I have the source code. I can't manage to support it well, yet people who don't have the source code can do a better job? In what universe?
Like the man said, support is basically limited to training and workarounds. Without access to the code, if an issue arises, all you *can* do is work around it. Some of these third parties are simply good at providing workarounds.
If I'm wrong, show me one service pack, for any version of Windows, that didn't come from Microsoft.