Wouldn't a backup of a full 250GB drive take more than 50 DVDs at 4.7GB each? (Also, if files are large, you'd have to either split them or use even more DVDs, right?)
(Please email any comments to me directly; I'm sure it wouldn't make an interesting debate!)
RTFA, indeed. The new story WAS about a display interface, and the submitter evidently did a search on "UDI" and jumped to the conclusion that Project UDI was related -- it's not.
Why do people insist on reusing names for unrelated things? Project UDI is a technology allowing device drivers to be portable across different operating systems and platforms. Project UDI doesn't address display technologies, much less DRM. This "Unified Display Interface" seems to be something entirely different, and it's unfortunate that they're trying to re-coin the "UDI" acronym. The UDI link in the summary is simply wrong.
On the other hand, Project UDI is a very cool technology that people should be supporting, so I guess the extra exposure could help, as long as people don't confuse UDI (Uniform Driver Interface) with UDI (Unified Display Interface)... *sigh*
Which is actually cheaper, soda or ice?
on
Ask The Mythbusters
·
· Score: 5, Interesting
Most restaurants seem to believe that ice is free, and therefore tend to overfill the ice to save money on soda. However, the energy required to freeze water to make ice should be considered -- is the real cost of ice actually less than the cost of an equivalent volume of soda?
That's why hardware manufacturers would like to see specifications like UDI and NDISfollowed. Unfortunately, those wonderful software people who are apparently so much better at this stuff have decided that they don't need anything as passe as a cross-platform driver API. Mr. Stallman is leading the charge on this one. Personally, I think he's stuck on stupid, but that's just me.
Isn't it obvious that every time someone successfully standardizes open interfaces, major leaps in productivity follow?
Without open standards, the Internet would not exist.
Many implementations of the Internet protocols were proprietary and it didn't matter.
The computer industry is starting to realize that XML, like TCP/IP, can bridge proprietary islands.
Operating systems and device drivers are full of proprietary islands just waiting to be bridged, and it could revolutionize operating systems as much as TCP/IP revolutionized computer networking.
Bridging all those islands would benefit free software immensely, regardless of whether or not proprietary closed-source vendors jump on the bandwagon.
The Internet wouldn't be where it is today without free software, yet free software wouldn't be where it is today without the Internet!
Project UDI could revolutionize free operating systems, but only if it is adopted as thoroughly as the Internet was.
Vendor-supplied UDI drivers would probably be less likely to be closed-source than people fear.
UDI drivers could (and should) be developed and distributed independently of OS kernels.
Adopting UDI would eliminate massive duplications of effort.
UDI is the best hope for the HURD, and would stimulate innovative competition between developers of various free operating systems.
The free software community should broadly adopt and embrace UDI out of self-interest, without regard to the behavior of proprietary companies.
This is a situation that calls for vision and foresight, not hindsight.
We've already lost years of the potential benefits of UDI -- let's not lose them entirely!
Ironically, this would be a perfect opportunity to turn the tables on the proprietary companies and benefit from their efforts!
The member companies of Project UDI should not be viewed as parasites in this matter.
Microsoft does not stand to benefit from Project UDI.
We should all be supporting Project UDI.
See the long version of this post for expanded discussion of these points...
[By the way -- AKAImBatman, please send me some email, I'd like to chat with you further about Project UDI...]
I hereby pledge that my hobby operating system will support Project UDI Core Spec version 1.01 from the very beginning.
Hopefully that wasn't sarcastic. I know, for my part, if I ever get around to writing a hobby operating system of my own (as I've long wanted to), I'd like to have UDI as the native driver interface. Of course, I never find any time to work on such things, but in principle that would be my goal.
I would hope every fringe OS developer would see the benefits of UDI and adopt it fully -- but the pool of resources represented by such projects is small compared to Linux or the major BSD systems. Maybe enough of the one-man OS projects could break the chicken-and-egg stalemate and make UDI more enticing for the larger players, but it would be so much better if a major OS would adopt UDI and start porting drivers...
I'm glad I'm not the only one who recognizes that Project UDI would benefit Linux and free software developers in general. Isn't it obvious that every time someone successfully standardizes open interfaces, major leaps in productivity follow?
Without open standards, the Internet would not exist. Various proprietary networking standards (Novell Netware, IBM channel architecture, Banyan Vines, etc.) used to work in their own isolated worlds, rarely speaking to each other. And people generally thought that was okay, because that's how it had always had been, and look how well each one works in its own little world! Similarly, email systems were proprietary and incompatible. Then along comes TCP/IP, SMTP and other open Internet protocols, and the world is transformed. Suddenly, everything can talk to everything, and with the 20/20 benefit of hindsight, it's clear to all how much better it is with the Internet than it was with all those proprietary islands.
Many implementations of the Internet protocols were proprietary and it didn't matter. There were always both free and proprietary implementations of the Internet protocols, but the important thing was that they all agreed on the same standards and (more or less) followed them, which bridged all those little proprietary islands into this wondrous whole we have today, where virtually any networked device is capable of communicating with any other. What mattered was that the standard was open, no matter how many of the implementations were proprietary. (And, of course, natural evolution tends to favor the extinction of most of the proprietary systems in favor of free software whenever such competition occurred, especially since vendor lock-in fails when customers demand conformance with open standards.)
The computer industry is starting to realize that XML, like TCP/IP, can bridge proprietary islands. Look at the number of legacy systems, interfaces, protocols and file formats which are being interfaced with XML to achieve at the application level what TCP/IP achieved at the networking level. Legacy systems, proprietary systems and even free systems, each with its own way of doing things, can suddenly be made to talk to each other in a robust, loosely-coupled fashion which was unfathomable just a decade or two ago. This process appears to be well on the way to revolutionizing the computer industry yet again.
Operating systems and device drivers are full of proprietary islands just waiting to be bridged, and it could revolutionize operating systems as much as TCP/IP revolutionized computer networking. Not all of these proprietary islands are "proprietary" in the closed-source sense -- many are also free-software islands which are "proprietary" in the "only works with this system" sense. Just in the domain of free software, there are countless little proprietary islands between various versions of Linux, FreeBSD, OpenBSD, NetBSD, Dragonfly BSD, Darwin, HURD, etc. These aren't "proprietary" as Stallman uses the term, but just try to take a random device driver from one of these random islands and dump it on another at random and see how likely it is to work without changes. Then, of course, there are also the truly proprietary systems such as Windows.
Bridging all those islands would benefit free software immensely, regardless of whether or not proprietary closed-source vendors jump on the bandwagon. Imagine if every device driver only needed to be implemented once to a common API, and it worked without source code changes on every operating system that supports that API? That's exactly the promise that Project UDI holds for operating systems and device drivers, and it's as revolutionary as the promise of TCP/IP.
The Internet wouldn't be where it is today without free software, yet free software wouldn't be where it is today without the Internet! This seems like a conundrum -- a chicken-and-egg problem. Actually, it's a truly symbiotic relationship, and it
I knew you were kidding, so I'm surprised you even bothered to research it. Of course, I've seen even stranger things, like feeding the video from a TV tuner into an ASCII translation. Incredibly, the example I saw was much more watchable than you would expect, considering the circumstances...
In any event, I don't have a webcam, so it's all moot. And supporting an ASCII webcam would be more of a joke feature than anything. Gangplank is a serious system -- it's designed to perform a basic communication function for its users, and perform it well. What it lacks in bells and whistles, it makes up for in simplicity, efficiency and stability. Convincing people to use it, that's another thing...
1) telnet is insecure. there is no way i would ever open up the telnet ports on my machines. i dont care if you tell me that inside the telnet port is a stash of delicious candies. dont go there girl!
Wow, a knee-jerk reaction if ever I saw one. Yes, TELNET is an insecure protocol -- everything goes over the wire in cleartext. That means that someone with the ability to snoop on your packets could get your login and password and use it to sign onto your account on the server. It's a risk, but only one of impersonation. If it's a small private community chat system, what's the real incentive to break into your account? Are people really so eager to impersonate you?
It doesn't mean they could use it to sign into your system account, unless you're dumb enough to use a secure password on an insecure system. Here's a hint: don't do that.
I'd love to support a secure protocol like SSH on the server, but that's easier said than done. As I said, it's a single-process server. I haven't been eager to try to implement the SSH protocol from scratch -- it was a lot of work implementing TELNET from scratch. Also, encrypted traffic would be much more computationally-expensive -- the current server is very efficient, but an encrypted server would probably be able to handle only a fraction of the user load possible with the TELNET protocol on the same hardware.
Still, SSH support is on my wishlist.
And if anyone has any ideas for securing the TELNET protocol better, I'm interested to hear them. (One option would be to have a custom client implementing a superset of the TELNET protocol...)
2) It uses "emacs style line editing" not vi style, which would clearly be the superior choice
There's no reason it couldn't use vi-style, it's just that I happened to prefer emacs-style, so that's what I implemented. The server is open-source -- feel free to add vi-style line editing yourself. Or you can try to convince me to write it, but I don't really have the time or inclination right now...
Gee, I didn't know there was such a demand for ASCII-based video chat. Feel free to write the client for that yourself...
I didn't say that the system won't ever have a client of its own -- one of these days, it will. However, I'll make sure that it continues to remain usable from a plain TELNET client, at least for the basic functionality that is already supported. Obviously, fancier features will likely require a client. If you want the fancy features, you take more risk of a security hole. If you want tried-and-true, you can stick with the traditional TELNET client and be sure that you're pretty safe...
There's always trade-offs. My system certainly isn't perfect, but at least it doesn't require a user to install a client. I'm not aware of any other IM system that actually targets TELNET as a client protocol. (Yes, I know that you can make certain systems work with TELNET clients, but it's not the preferred client, and not designed to be a powerful, user-friendly interface.)
I might as well take this opportunity to plug my open-source "IM" system (CMC), Gangplank, which doesn't require an IM client.
Gangplank was written to support the standard TELNET protocol, meaning any standard TELNET client can be used to connect to the system. Despite not using a custom client, the server supports remote character echo, full (RFC-compliant) TELNET protocol support, Emacs-style line editing, input redrawing when output occurs, and a full input history buffer -- all in a nonblocking, single-process server driven by a select() loop. The system lacks some features (like file transfer), but it is well-suited for a community of people to communicate with each other via text messages. The server is fast and efficient, and it should be able to support thousands of users on a single server. (I've never been able to test the limits of the server, but it uses negligible CPU time...)
And to stay on topic, using a TELNET client should protect you against "IM worms" since there are a wide variety of independent TELNET client implementations on various operating systems, TELNET has been around for decades and standard clients are probably fairly well debugged by now...
Re:What other pre-web services are out there?
on
IMDb Turns 15
·
· Score: 1
Its easy to see that the IMDB is one of the oldest if not the oldest internet services (I'm not talking about protocols). And it also predates the web. I was wondering if any of you could name other Internet services that predate the web and still exist today. What constitutes a service is probably difficult because things like IMDB made a move from Usenet to Web which are two very different protocols (although they used them simularly).
If you count reimplementations, Rensselaer Polytechnic Institute (RPI) has a long history of Computer-Mediated Communications (CMC) systems (i.e. "chat" or "IM" systems) that predate IRC as well as the World-Wide Web. I believe the first one may even predate Bitnet Relay. This series of systems might constitute a "service", in that each one served the same purpose (allowing users to talk to each other) and the same user base followed from one system to another until the present day:
Around 1984, students in the RPI-ACM created the "CB" program, which took the place of chatting (in "vamp mode") via the MTS system's *FORUM service (which was a bit like a proto-blog, I suppose).
In 1986, a complete rewrite of the system was made, and named "CONNECT". All of the users moved from CB to CONNECT, which was quite superior.
There was a vaporware project called "Connect-2" that was active around 1988-1990 -- this was to be an advanced object-oriented successor to CONNECT, but it was never actually written, despite the dozens of people who were actively involved with the project. (Some interesting design documents were created, however.)
Another system, "Clover" was started in December 1989, and all the CONNECT users moved to this system after the CONNECT system was shut down (for political reasons) on June 30, 1991. Clover was the first in this line of CMC systems written for a Unix system instead of the MTS operating system that RPI used for its mainframe.
Another CONNECT-like CMC system (which I wrote) was Gangplank, which was previously known as "Phoenix". (In its earliest days, it was just called "conf" and written in C, but this was just in the few months since development began on November 30, 1992 -- the system was soon rewritten in C++ and renamed.) I renamed the system on November 30, 2001 when I released the source code under an Open Source license. Originally, I wrote this server to talk to family members who couldn't use CONNECT. Later, I hoped it might replace Clover, but it wasn't ready enough until it was too late to interest the existing users. Gangplank is unique in that it implements the TELNET protocol directly (along with remote echo, line editing, input history, etc.) instead of using a client application. (I'm not aware of any other CMC system that provides such a user-friendly interface directly to TELNET clients...)
In early 1994, one of the authors of Clover wrote yet another new CMC system from scratch, named lily. Again, this system was similar (from a user perspective) to CONNECT and Clover, but it was a complete platform change again. Although still running on Unix, lily is implemented in the LambdaMOO programming language. Again, the entire user base transitioned to a replacement system, moving from Clover to lily. The lily system remains in active use today. This is also an open source system, but the main server is the RPI server that the old user base migrated to.
RPI's "CMC service" might qualify as a "pre-web" service according to your definition -- although the users migrated from C
One reason I personally might work on such a project would be there was a chance that otherwise the GPL version might become outdated, and offer users no choice other than `proprietary or nothing`.
So what? If the GPL version is already good enough, why worry about the bells and whistles added to the proprietary version? It's not an arms race -- either the software meets your needs or it doesn't.
And if it's not good enough, why weren't you already working on it?
I think the question is: Why would/should anyone develop the GPL version of the project only after the company has reverted to a proprietary license, when they weren't interested enough to help the company with the GPL code on a cooperative basis?
And others are perfectly content calling people communists, cancer and zealots.
Nice try. I'm no fan of closed-source software (and I despise Microsoft) -- I've been a free-software advocate since 1987. I wasn't calling anyone a communist, and I would never refer to the GPL as a "cancer" -- although I do recognize that the GPL may reasonably be described as a "viral" license. While that term may carry negative connotations, it is descriptive -- if someone describes a license (other than the GPL) as "viral", wouldn't you know exactly what they meant? (Besides, that "viral" behavior is the GPL's entire raison d'etre, after all...)
But you'd have to be blind not to see that there are some zealots in our midst. My point was that someone who was unwilling to help with the code when the company was supporting the code under the GPL license -- but then suddenly becomes motivated to work on the project when the company gives up on the GPL -- clearly isn't motivated by improving that software, or they would have been doing so already. Only a zealot would find motivation in punishing a company for abandoning the GPL, having already shown no interest when the company was on their side.
(Wow, I think this is my first "Flamebait" moderation ever! That's what I get for brevity...)
I'm not familiar with this Nessus project, but it sounds like a for-profit company has been publishing source code for their main project, under the GPL, and they've been taken for granted by the free software community and taken advantage of by their competitors. Is it really a surprise that they would question the wisdom of publishing under the GPL, given such circumstances?
Let's face it -- however much we may say it's about "free speech" instead of "free beer", it's really about both. And in this case, it appears to be more about the "free beer" if people have been eager to use the software but unwilling to contribute any code changes. Well, it seems that the company is going to keep offering the "free beer" without the "free speech". Use it or lose it, I guess -- if the users of this software were truly all that interested in the code, maybe they should have been contributing back to the project, so they'd actually have something to lose by dropping the GPL.
If the users can't be bothered to contribute to the project while it's sponsored by the company under the GPL, but then they DO find themselves motivated by the change back to a proprietary license, that's a very sad and ironic situation -- which is the point I was trying to make. We should be more motivated by cooperation and improving the software, not by having an enemy to strive against. Yet we'll probably see someone fork the GPL code and take on the battle as a matter of principle -- but why couldn't they have helped with the code before the company decided this GPL thing wasn't working out?
Assuming that the project was "taken care of" amounts to taking the sponsoring company for granted. But we have to remember that unlike individuals (who may have altruistic motives), for-profit companies need to be profitable, and EVERY time a company decides that using the GPL is unprofitable -- especially if they have data to back it up -- is a setback for the free software community as a whole. Other companies who might have been considering adopting the GPL will think twice when they discover companies who have regretted the decision...
Now, I fully realize that there are too many projects out there that are deserving of attention, and perhaps there was nobody in the free software community who was really interested in developing this software. That's fine if that's the case, but the corollary is that they should still be uninterested when this project returns to a closed-source development model. The alternative is that the users who could and should have been helping out with this project were taking advantage of the company's generosity as much as the competitors were, which would mean that they brought this result upon themselves by taking the company for granted.
We can't assume that for-profit companies will choose to create free software just because it's the right thing to do -- it has to be in their best interest. As a community, we should probably make a point of supporting those companies who have put their business on the line by releasing their code under the GPL, and make sure the risk they're taking is worthwhile, rather than taking the companies for granted. Otherwise, we may see the pendulum swing the other way, and if a new trend away from the GPL develops, it may be very hard to convince the corporate world to give free software another chance someday...
Re:nessus is dead, long live gnessus?
on
Nessus Closes Source
·
· Score: 1, Flamebait
Either the developer is understating the community involvement or he wasn't that good at drumming up interest in community involvement.
Or maybe the community couldn't give a damn about helping until it's an underdog project competing against an evil proprietary product? Some people are more motivated by zealotry than improving the world...
Even if the levies were continued funded since 2003, would there have been enough time to fortify them for a Category 5 hurricane? 2005 would have likely been the second year of the project.
Yes, it probably would have saved most of New Orleans -- not because the levees would have been ready yet to protect against Category 5 hurricanes, but because Katrina didn't surge over the top of the levees -- the levees failed to hold back water levels that were lower than the top of the levees, after Katrina was gone, when New Orleans thought it had escaped the worst-case scenario of devastating floods.
If the levees had been strengthened before Katrina hit, this failure might not have occurred, and the limited flooding in New Orleans originally reported would have been a brief national news story and thereafter an issue of local concern.
Instead, because of failures in leadership at all levels (especially the governor of Lousiana and the mayor of New Orleans, who should both be charged with involuntary manslaughter for their incompetence) and a penny-wise, pound-foolish shortsightedness (having saved $150 million on levee maintenance, we may now have to spend $150 billion to rebuild New Orleans), we now have the "natural" disaster of the century...
I wasn't planning to weigh in on this complex topic, but I can't let this bad advice pass without comment:
Maildir message store.
Store the mail in maildirs. [...]
Don't use Maildir! It does not scale well at all. Maildir's claimed greatest strength is the ability to use an NFS-mounted spool without locking. While this is true, Maildir has a fatal flaw that more than outweighs this benefit.
Because Maildir encodes flag information into the filename, constant rescanning of the mail spool directories is inevitable, and the network traffic for these directory scans will kill the performance. Worse yet, NFS caching can cause different servers to have different views of the same mailbox at the same time.
How do I know this? I once tried to implement a scalable mail architecture for a former employer using Linux servers and NetApp NFS servers. On paper, Maildir sounded like a great solution, since NFS locking would not be required. After implementation, we discovered how expensive all those directory scans are -- the performance was a fraction of what it might have been with a better mailbox format.
Now, a format similar to Maildir (one file per message, no NFS locking), which NEVER renames files once created, might have a lot of potential. Of course, this would require either an index file or a database for metadata, and perhaps some direct server-to-server notification of new email, but Maildir's promised advantages might be achievable without its Achille's heel of the massive overhead of constant directory scanning.
Another thing I learned from that project: Qmail sucks for this! It may work well on small systems with a few user accounts on a single server, but it is nearly impossible to adapt to a scalable multi-server environment where the users have no system accounts. The source code is so convoluted and obfuscated that it's incomprehensible, and it's so poorly modularized that customization is a serious nightmare.
Against my better judgment, I agreed to use qmail for the project after heavy lobbying by a new employee who left the company soon thereafter. I spent several frustrating weeks fighting with the horrible qmail codebase, trying to integrate it with an external database system to control delivery of the email -- it was ridiculous.
After the qmail evangelist quit, I immediately dumped qmail and started from scratch with sendmail. Integrating the database into sendmail was a snap -- I just created a new "map" type, which was a very cleanly modularized piece of code, then I made a few modifications to the config file and it Just Worked. In a day or two, I was able to accomplish the goal that wasn't even close after 2-3 weeks of dealing with the morass of qmail's source code.
I'm now convinced that qmail's vaunted "security" is merely "security through obscurity", and I just don't trust the software. But as long as you don't want to do something different than qmail expects, it seems to work fine for many people with small, simple systems. Forget about using it for an enterprise email system.
I don't want to try to describe the email system that I would design in this situation, but I would avoid "one big server" designs and focus more on multi-server designs where platform reliability depends on server redundancy. (Think Google!)
Ideally, you should be able to rip any given server out of the rack without notice (simulating a crash), rebuild a replacement from scratch and put it into service -- all without affecting the users in any noticable way. Designing "stateless" servers where the service data is not local can help here. (For inspiration here, read Earthlink's white papers: A Scalable News Architecture on a Single Spool and A Highly Scalable Electronic Mail Service Using Open Systems)
Good luck designing this system. It's not a trivial task, and what some people evangelize (because it works on a small scale) will be inappropriate and fall apart on a large scale...
There are good arguments for both static and dynamic linking -- neither is inherently better than the other for all situations.
What we really need is the ability to take a statically-linked binary and relink it with a new version of an included library like this, without requiring the source or object files. (Of course, this would require retaining relocation information in the binary.)
If relinking were possible, needed security fixes could be safely relinked into existing static binaries on demand, without risking random breakage from library upgrades...
Slashdot Mirror
Wouldn't a backup of a full 250GB drive take more than 50 DVDs at 4.7GB each? (Also, if files are large, you'd have to either split them or use even more DVDs, right?)
(Please email any comments to me directly; I'm sure it wouldn't make an interesting debate!)
17576 three letter acronyms should be enough for anybody.
Must everything be a TLA?
RTFA, indeed. The new story WAS about a display interface, and the submitter evidently did a search on "UDI" and jumped to the conclusion that Project UDI was related -- it's not.
Why do people insist on reusing names for unrelated things? Project UDI is a technology allowing device drivers to be portable across different operating systems and platforms. Project UDI doesn't address display technologies, much less DRM. This "Unified Display Interface" seems to be something entirely different, and it's unfortunate that they're trying to re-coin the "UDI" acronym. The UDI link in the summary is simply wrong.
On the other hand, Project UDI is a very cool technology that people should be supporting, so I guess the extra exposure could help, as long as people don't confuse UDI (Uniform Driver Interface) with UDI (Unified Display Interface)... *sigh*
Most restaurants seem to believe that ice is free, and therefore tend to overfill the ice to save money on soda. However, the energy required to freeze water to make ice should be considered -- is the real cost of ice actually less than the cost of an equivalent volume of soda?
I would very much like to see UDI widely adopted -- I believe it's a technology the world needs.
Send me some email, let's talk about it more...
My comment was in no way sarcastic. My OS WILL have UDI built-in as its native driver interface right from the start.
Good to hear. We need more UDI-native operating systems...
Hey, send me some email so we can still discuss this when this thread is dead and gone!
See the long version of this post for expanded discussion of these points...
[By the way -- AKAImBatman, please send me some email, I'd like to chat with you further about Project UDI...]
I hereby pledge that my hobby operating system will support Project UDI Core Spec version 1.01 from the very beginning.
Hopefully that wasn't sarcastic. I know, for my part, if I ever get around to writing a hobby operating system of my own (as I've long wanted to), I'd like to have UDI as the native driver interface. Of course, I never find any time to work on such things, but in principle that would be my goal.
I would hope every fringe OS developer would see the benefits of UDI and adopt it fully -- but the pool of resources represented by such projects is small compared to Linux or the major BSD systems. Maybe enough of the one-man OS projects could break the chicken-and-egg stalemate and make UDI more enticing for the larger players, but it would be so much better if a major OS would adopt UDI and start porting drivers...
I'm glad I'm not the only one who recognizes that Project UDI would benefit Linux and free software developers in general. Isn't it obvious that every time someone successfully standardizes open interfaces, major leaps in productivity follow?
Without open standards, the Internet would not exist. Various proprietary networking standards (Novell Netware, IBM channel architecture, Banyan Vines, etc.) used to work in their own isolated worlds, rarely speaking to each other. And people generally thought that was okay, because that's how it had always had been, and look how well each one works in its own little world! Similarly, email systems were proprietary and incompatible. Then along comes TCP/IP, SMTP and other open Internet protocols, and the world is transformed. Suddenly, everything can talk to everything, and with the 20/20 benefit of hindsight, it's clear to all how much better it is with the Internet than it was with all those proprietary islands.
Many implementations of the Internet protocols were proprietary and it didn't matter. There were always both free and proprietary implementations of the Internet protocols, but the important thing was that they all agreed on the same standards and (more or less) followed them, which bridged all those little proprietary islands into this wondrous whole we have today, where virtually any networked device is capable of communicating with any other. What mattered was that the standard was open, no matter how many of the implementations were proprietary. (And, of course, natural evolution tends to favor the extinction of most of the proprietary systems in favor of free software whenever such competition occurred, especially since vendor lock-in fails when customers demand conformance with open standards.)
The computer industry is starting to realize that XML, like TCP/IP, can bridge proprietary islands. Look at the number of legacy systems, interfaces, protocols and file formats which are being interfaced with XML to achieve at the application level what TCP/IP achieved at the networking level. Legacy systems, proprietary systems and even free systems, each with its own way of doing things, can suddenly be made to talk to each other in a robust, loosely-coupled fashion which was unfathomable just a decade or two ago. This process appears to be well on the way to revolutionizing the computer industry yet again.
Operating systems and device drivers are full of proprietary islands just waiting to be bridged, and it could revolutionize operating systems as much as TCP/IP revolutionized computer networking. Not all of these proprietary islands are "proprietary" in the closed-source sense -- many are also free-software islands which are "proprietary" in the "only works with this system" sense. Just in the domain of free software, there are countless little proprietary islands between various versions of Linux, FreeBSD, OpenBSD, NetBSD, Dragonfly BSD, Darwin, HURD, etc. These aren't "proprietary" as Stallman uses the term, but just try to take a random device driver from one of these random islands and dump it on another at random and see how likely it is to work without changes. Then, of course, there are also the truly proprietary systems such as Windows.
Bridging all those islands would benefit free software immensely, regardless of whether or not proprietary closed-source vendors jump on the bandwagon. Imagine if every device driver only needed to be implemented once to a common API, and it worked without source code changes on every operating system that supports that API? That's exactly the promise that Project UDI holds for operating systems and device drivers, and it's as revolutionary as the promise of TCP/IP.
The Internet wouldn't be where it is today without free software, yet free software wouldn't be where it is today without the Internet! This seems like a conundrum -- a chicken-and-egg problem. Actually, it's a truly symbiotic relationship, and it
Suggestion: telnet-ssl.
Yes, in principle, I could tunnel TELNET through SSL. I'm not sure if that would actually be easier than implementing SSH in some fashion.
Also, how common is SSL support in TELNET clients?
Deven
I knew you were kidding, so I'm surprised you even bothered to research it. Of course, I've seen even stranger things, like feeding the video from a TV tuner into an ASCII translation. Incredibly, the example I saw was much more watchable than you would expect, considering the circumstances...
In any event, I don't have a webcam, so it's all moot. And supporting an ASCII webcam would be more of a joke feature than anything. Gangplank is a serious system -- it's designed to perform a basic communication function for its users, and perform it well. What it lacks in bells and whistles, it makes up for in simplicity, efficiency and stability. Convincing people to use it, that's another thing...
1) telnet is insecure. there is no way i would ever open up the telnet ports on my machines. i dont care if you tell me that inside the telnet port is a stash of delicious candies. dont go there girl!
Wow, a knee-jerk reaction if ever I saw one. Yes, TELNET is an insecure protocol -- everything goes over the wire in cleartext. That means that someone with the ability to snoop on your packets could get your login and password and use it to sign onto your account on the server. It's a risk, but only one of impersonation. If it's a small private community chat system, what's the real incentive to break into your account? Are people really so eager to impersonate you?
It doesn't mean they could use it to sign into your system account, unless you're dumb enough to use a secure password on an insecure system. Here's a hint: don't do that.
I'd love to support a secure protocol like SSH on the server, but that's easier said than done. As I said, it's a single-process server. I haven't been eager to try to implement the SSH protocol from scratch -- it was a lot of work implementing TELNET from scratch. Also, encrypted traffic would be much more computationally-expensive -- the current server is very efficient, but an encrypted server would probably be able to handle only a fraction of the user load possible with the TELNET protocol on the same hardware.
Still, SSH support is on my wishlist.
And if anyone has any ideas for securing the TELNET protocol better, I'm interested to hear them. (One option would be to have a custom client implementing a superset of the TELNET protocol...)
2) It uses "emacs style line editing" not vi style, which would clearly be the superior choice
There's no reason it couldn't use vi-style, it's just that I happened to prefer emacs-style, so that's what I implemented. The server is open-source -- feel free to add vi-style line editing yourself. Or you can try to convince me to write it, but I don't really have the time or inclination right now...
Gee, I didn't know there was such a demand for ASCII-based video chat. Feel free to write the client for that yourself...
I didn't say that the system won't ever have a client of its own -- one of these days, it will. However, I'll make sure that it continues to remain usable from a plain TELNET client, at least for the basic functionality that is already supported. Obviously, fancier features will likely require a client. If you want the fancy features, you take more risk of a security hole. If you want tried-and-true, you can stick with the traditional TELNET client and be sure that you're pretty safe...
There's always trade-offs. My system certainly isn't perfect, but at least it doesn't require a user to install a client. I'm not aware of any other IM system that actually targets TELNET as a client protocol. (Yes, I know that you can make certain systems work with TELNET clients, but it's not the preferred client, and not designed to be a powerful, user-friendly interface.)
I might as well take this opportunity to plug my open-source "IM" system (CMC), Gangplank, which doesn't require an IM client.
Gangplank was written to support the standard TELNET protocol, meaning any standard TELNET client can be used to connect to the system. Despite not using a custom client, the server supports remote character echo, full (RFC-compliant) TELNET protocol support, Emacs-style line editing, input redrawing when output occurs, and a full input history buffer -- all in a nonblocking, single-process server driven by a select() loop. The system lacks some features (like file transfer), but it is well-suited for a community of people to communicate with each other via text messages. The server is fast and efficient, and it should be able to support thousands of users on a single server. (I've never been able to test the limits of the server, but it uses negligible CPU time...)
And to stay on topic, using a TELNET client should protect you against "IM worms" since there are a wide variety of independent TELNET client implementations on various operating systems, TELNET has been around for decades and standard clients are probably fairly well debugged by now...
If you count reimplementations, Rensselaer Polytechnic Institute (RPI) has a long history of Computer-Mediated Communications (CMC) systems (i.e. "chat" or "IM" systems) that predate IRC as well as the World-Wide Web. I believe the first one may even predate Bitnet Relay. This series of systems might constitute a "service", in that each one served the same purpose (allowing users to talk to each other) and the same user base followed from one system to another until the present day:
RPI's "CMC service" might qualify as a "pre-web" service according to your definition -- although the users migrated from C
One reason I personally might work on such a project would be there was a chance that otherwise the GPL version might become outdated, and offer users no choice other than `proprietary or nothing`.
So what? If the GPL version is already good enough, why worry about the bells and whistles added to the proprietary version? It's not an arms race -- either the software meets your needs or it doesn't.
And if it's not good enough, why weren't you already working on it?
Yes, but was that the question?
I think the question is: Why would/should anyone develop the GPL version of the project only after the company has reverted to a proprietary license, when they weren't interested enough to help the company with the GPL code on a cooperative basis?
And others are perfectly content calling people communists, cancer and zealots.
Nice try. I'm no fan of closed-source software (and I despise Microsoft) -- I've been a free-software advocate since 1987. I wasn't calling anyone a communist, and I would never refer to the GPL as a "cancer" -- although I do recognize that the GPL may reasonably be described as a "viral" license. While that term may carry negative connotations, it is descriptive -- if someone describes a license (other than the GPL) as "viral", wouldn't you know exactly what they meant? (Besides, that "viral" behavior is the GPL's entire raison d'etre, after all...)
But you'd have to be blind not to see that there are some zealots in our midst. My point was that someone who was unwilling to help with the code when the company was supporting the code under the GPL license -- but then suddenly becomes motivated to work on the project when the company gives up on the GPL -- clearly isn't motivated by improving that software, or they would have been doing so already. Only a zealot would find motivation in punishing a company for abandoning the GPL, having already shown no interest when the company was on their side.
Maybe, or maybe both. Isn't competition supposed to be healthy?
Sure, but isn't cooperation usually preferable?
(Wow, I think this is my first "Flamebait" moderation ever! That's what I get for brevity...)
I'm not familiar with this Nessus project, but it sounds like a for-profit company has been publishing source code for their main project, under the GPL, and they've been taken for granted by the free software community and taken advantage of by their competitors. Is it really a surprise that they would question the wisdom of publishing under the GPL, given such circumstances?
Let's face it -- however much we may say it's about "free speech" instead of "free beer", it's really about both. And in this case, it appears to be more about the "free beer" if people have been eager to use the software but unwilling to contribute any code changes. Well, it seems that the company is going to keep offering the "free beer" without the "free speech". Use it or lose it, I guess -- if the users of this software were truly all that interested in the code, maybe they should have been contributing back to the project, so they'd actually have something to lose by dropping the GPL.
If the users can't be bothered to contribute to the project while it's sponsored by the company under the GPL, but then they DO find themselves motivated by the change back to a proprietary license, that's a very sad and ironic situation -- which is the point I was trying to make. We should be more motivated by cooperation and improving the software, not by having an enemy to strive against. Yet we'll probably see someone fork the GPL code and take on the battle as a matter of principle -- but why couldn't they have helped with the code before the company decided this GPL thing wasn't working out?
Assuming that the project was "taken care of" amounts to taking the sponsoring company for granted. But we have to remember that unlike individuals (who may have altruistic motives), for-profit companies need to be profitable, and EVERY time a company decides that using the GPL is unprofitable -- especially if they have data to back it up -- is a setback for the free software community as a whole. Other companies who might have been considering adopting the GPL will think twice when they discover companies who have regretted the decision...
Now, I fully realize that there are too many projects out there that are deserving of attention, and perhaps there was nobody in the free software community who was really interested in developing this software. That's fine if that's the case, but the corollary is that they should still be uninterested when this project returns to a closed-source development model. The alternative is that the users who could and should have been helping out with this project were taking advantage of the company's generosity as much as the competitors were, which would mean that they brought this result upon themselves by taking the company for granted.
We can't assume that for-profit companies will choose to create free software just because it's the right thing to do -- it has to be in their best interest. As a community, we should probably make a point of supporting those companies who have put their business on the line by releasing their code under the GPL, and make sure the risk they're taking is worthwhile, rather than taking the companies for granted. Otherwise, we may see the pendulum swing the other way, and if a new trend away from the GPL develops, it may be very hard to convince the corporate world to give free software another chance someday...
Either the developer is understating the community involvement or he wasn't that good at drumming up interest in community involvement.
Or maybe the community couldn't give a damn about helping until it's an underdog project competing against an evil proprietary product? Some people are more motivated by zealotry than improving the world...
Even if the levies were continued funded since 2003, would there have been enough time to fortify them for a Category 5 hurricane? 2005 would have likely been the second year of the project.
Yes, it probably would have saved most of New Orleans -- not because the levees would have been ready yet to protect against Category 5 hurricanes, but because Katrina didn't surge over the top of the levees -- the levees failed to hold back water levels that were lower than the top of the levees, after Katrina was gone, when New Orleans thought it had escaped the worst-case scenario of devastating floods.
If the levees had been strengthened before Katrina hit, this failure might not have occurred, and the limited flooding in New Orleans originally reported would have been a brief national news story and thereafter an issue of local concern.
Instead, because of failures in leadership at all levels (especially the governor of Lousiana and the mayor of New Orleans, who should both be charged with involuntary manslaughter for their incompetence) and a penny-wise, pound-foolish shortsightedness (having saved $150 million on levee maintenance, we may now have to spend $150 billion to rebuild New Orleans), we now have the "natural" disaster of the century...
I wasn't planning to weigh in on this complex topic, but I can't let this bad advice pass without comment:
Maildir message store.
Store the mail in maildirs. [...]
Don't use Maildir! It does not scale well at all. Maildir's claimed greatest strength is the ability to use an NFS-mounted spool without locking. While this is true, Maildir has a fatal flaw that more than outweighs this benefit.
Because Maildir encodes flag information into the filename, constant rescanning of the mail spool directories is inevitable, and the network traffic for these directory scans will kill the performance. Worse yet, NFS caching can cause different servers to have different views of the same mailbox at the same time.
How do I know this? I once tried to implement a scalable mail architecture for a former employer using Linux servers and NetApp NFS servers. On paper, Maildir sounded like a great solution, since NFS locking would not be required. After implementation, we discovered how expensive all those directory scans are -- the performance was a fraction of what it might have been with a better mailbox format.
Now, a format similar to Maildir (one file per message, no NFS locking), which NEVER renames files once created, might have a lot of potential. Of course, this would require either an index file or a database for metadata, and perhaps some direct server-to-server notification of new email, but Maildir's promised advantages might be achievable without its Achille's heel of the massive overhead of constant directory scanning.
Another thing I learned from that project: Qmail sucks for this! It may work well on small systems with a few user accounts on a single server, but it is nearly impossible to adapt to a scalable multi-server environment where the users have no system accounts. The source code is so convoluted and obfuscated that it's incomprehensible, and it's so poorly modularized that customization is a serious nightmare.
Against my better judgment, I agreed to use qmail for the project after heavy lobbying by a new employee who left the company soon thereafter. I spent several frustrating weeks fighting with the horrible qmail codebase, trying to integrate it with an external database system to control delivery of the email -- it was ridiculous.
After the qmail evangelist quit, I immediately dumped qmail and started from scratch with sendmail. Integrating the database into sendmail was a snap -- I just created a new "map" type, which was a very cleanly modularized piece of code, then I made a few modifications to the config file and it Just Worked. In a day or two, I was able to accomplish the goal that wasn't even close after 2-3 weeks of dealing with the morass of qmail's source code.
I'm now convinced that qmail's vaunted "security" is merely "security through obscurity", and I just don't trust the software. But as long as you don't want to do something different than qmail expects, it seems to work fine for many people with small, simple systems. Forget about using it for an enterprise email system.
I don't want to try to describe the email system that I would design in this situation, but I would avoid "one big server" designs and focus more on multi-server designs where platform reliability depends on server redundancy. (Think Google!)
Ideally, you should be able to rip any given server out of the rack without notice (simulating a crash), rebuild a replacement from scratch and put it into service -- all without affecting the users in any noticable way. Designing "stateless" servers where the service data is not local can help here. (For inspiration here, read Earthlink's white papers: A Scalable News Architecture on a Single Spool and A Highly Scalable Electronic Mail Service Using Open Systems)
Good luck designing this system. It's not a trivial task, and what some people evangelize (because it works on a small scale) will be inappropriate and fall apart on a large scale...
There are good arguments for both static and dynamic linking -- neither is inherently better than the other for all situations.
What we really need is the ability to take a statically-linked binary and relink it with a new version of an included library like this, without requiring the source or object files. (Of course, this would require retaining relocation information in the binary.)
If relinking were possible, needed security fixes could be safely relinked into existing static binaries on demand, without risking random breakage from library upgrades...