I was being sarcastic, but since you brought it up...
GNU is _not_ a complete system minus a kernel. Take a basic Linux distribution (or better yet, take a basic Linux distribution from 5-8 years ago). A lot of it is GNU, but a lot of it is not. X, virtually all the network tools (both client and server), virtually all of the common daemons (slightly important ones like init, cron, lpd), and other basic stuff (like/bin/login) were not from GNU because the GNU project did not have such. GNU had a C compiler, a partially working C library (did you ever try to use GNU libc version 1?), some basic commands like ls, grep, find, awk, sed, and emacs. The myth that GNU was complete except for a kernel is false. Only by adding other stuff (some from BSD, some from the X Consortium, some other freely available software, and some written from scratch) did it become Linux.
A good bit of the development that helped some of the GNU tools (especially the C library) get to the point they are today was spurred by Linux. H.J. Lu (and many others) did an admirable job getting the old GNU C library into a state where it could really be the C library for an operating system. Ever look at the old GNU termcap library? I did, and it did not work for a lot of cases. Since then, ncurses has been claimed by GNU. Nice things like the color extensions for ls first appeared in Linux distributions and only later were they (sometimes only grudgingly) integrated into the GNU source. I haven't looked at what makes up the HURD system; how much was written by GNU for GNU? Did they write their own telnet (or ssh) daemon? What about init and login? All the world is not emacs; a lot of people use vi (and joe and jed and pico, even if it is non-free).
Does GNU deserve credit? Yes. Should it be called GNU/Linux (or that horrid "Lignux" that RMS tried to push)? No. Development does not come out of a vacuum. Linux stands on many shoulders, and GNU is one of them. To hear RMS talk about it though, you'd think Tux is standing on the GNU's foot. The rest of the world doesn't try to tack their name on Hurd; GNU should try to build on their own (excellent) reputation without trying to latch on to Linux.
Shouldn't that be Linux/Hurd?
on
Hurd: H2 CD Images
·
· Score: 0, Flamebait
Gee, Hurd is using package tools developed originally for Linux (and C library work that was done for Linux, and compiler improvements that were driven by Linux users, and...), so RMS should give credit where credit is due. It should be more properly called Linux/Hurd, or maybe just HurL.
Alan Cox made a number of statements about the US DMCA and the Skylarov
case. He advised others not to travel to the US and resigned his
membership on the Usenix ALS committee, citing the DMCA.
Now, if the UK passes this treaty (with the same objectionable
provisions as the DMCA), where will he go? Is Alan going to leave the
UK?
Are they going to drop the text of the GNU General Public License? I
quote:
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
No modification is allowed at all. According to the
Debian Free
Software Guidelines (which they are now applying to ALL included
works, not just software), they require that modifications are allowed.
If they drop the text of the license, then they'd have to drop every
package licensed under the GPL (as the license requires including a copy
of the license).
Slaskware was not the first commercial distribution of Linux. Slackware
just started as a set of patches and fixes on top of SLS (Soft Landing
Software IIRC), which I believe was the first commercial Linux
distribution (but not the first distribution). Yggdrasil also had an
early release available about the time of the first public Slackware
release.
The EFF says:
And anti-spam blacklists, such as the MAPS RBL (Mail Abuse Prevention
System Realtime Blackhole List, the most popular), result in a large
number of Internet service providers (ISPs) surrepticiously blocking
large amounts of non-spam from innocent people. This is because they
block all email from entire IP address blocks--even from entire nations.
This is done with no notice to the users, who do not even know that
their mail is not being delivered.
Inaccuracies:
"surrepticiously blocking": I have not run across an ISP that won't
tell you they use MAPS
"entire IP address blocks": The MAPS RBL and RSS lists list the IPs
of individual servers, not large blocks. The only MAPS list that
lists large blocks is the DUL (Dial-Up List), which lists IP blocks
of dial-up users (voluntarily contributed by ISPs to help block
direct-to-MX spam).
"even from entire nations": IP blocks are only somewhat assigned
according to international boundaries (and see previous entry about
large IP blocks).
"no notice to the users": Most ISPs will announce that they use MAPS
and other anti-spam methods to their users because it shows that the
ISP is trying to do something about the spam their users hate.
"who do not even know that their mail is not being delivered": The
typical use of the MAPS lists causes messages to be rejected, so the
sender is notified that their message was not delivered.
Also, some server admins configure their mail servers to tag
messages instead of rejecting them (so they are still delivered, but
users can filter on the tag in their mail client).
And that is just the second paragraph.
Email is not protected speech, anymore than snail mail is.
Senders don't have the right to force recipients to read their mail.
The owner of the recipient's mail box (the US Government in the case of
US snail mail) has the right to decline to deliver some types of mail.
There are quite a few things that the US Post Office won't deliver
(including "suspicious" packages). A package may be suspicious because
it has no return address and white powder leaking out, or it may be
suspicious because of where it originated (be it a post office in New
Jersey or a mail server at a particular IP address).
Another comparison can be made to the telephone system. I recently
added a feature on my telephone service that blocks "unknown callers"
(people, usually telemarketers, that don't allow their caller-ID
information to be sent). Those calls are blocked at the carrier. The
US Post Office and the telephone companies are "common carriers" and
have to carry most communication, but they are allowed to block some.
ISPs are not common carriers; they can refuse to carry whatever
they don't like.
The MAPS RBL also rarely (if ever) blocks "legitimate" mail. The
servers on the RBL are the servers for large spam houses that are repeat
offenders and refuse to do anything about it. The RSS list does hit
some legitimate email, but not much. These are lists of irresponsible
mail servers. Just as it is irresponsible to yell "fire" in a crowded
theater, it is irresponsible to run a mail server that allows third
party relay.
There are some other DNS based blacklists that do get more
"collateral damage" (sometimes intentionally). Guess what: they are not
nearly as widely used as the MAPS lists. ISPs want to deliver
legitimate email, because not doing so will cause unhappy customers (or
no customers). However, at the same time, customers are screaming at
ISPs to get rid of the spam, so each ISP has to make up its own mind as
to what steps it will follow to answer the demands of customers.
Virtually every project I've been involved with have welcomed good code. Sometimes, changes are rejected because they don't fit with the maintainers' "big picture" view of where they want a project to view, but usually they'll explain themselves if that is the case (and you can try to adapt your change or their viewpoint:-) ).
I've submitted code to some projects (like util-linux, sendmail, and GNU libtermcap) and had my ideas accepted but someone else made the change (in ways that better fit the "big picture"). Nothing on my patches page for Cistron RADIUS has been integrated into that code, but that is because Cistron RADIUS is considered "stable" and doesn't get much in the way of feature changes (new features go into FreeRADIUS). I've had patches accepted for OpenSSH, wu-ftpd, and Cyrus SASL that went right into the core code base. When I suggested a change for Cricket (which is maintained on SourceForge), I was given direct access to the CVS tree and basically told to "make it so!"
Don't give up because your changes are not accepted. Talk to the maintainers, and if it is clear that they aren't interested, put your patches up on a web page and let others know about them. If they are useful and people use them, the original maintainers may decide to pick them up. If not, that's okay too - thats one of the great things about Open Source software!
The problem is that they pulled a fast one on beta testers (and the public in general). I don't know how many people outside of Sistina helped with beta testing, but they aren't going to see a buck for their effort. Neither will the people that built the VFS layer in Linux (or Linux in general) see any bucks for their contribution (GFS is built on Linux after all).
They expect to get back any changes that are made. In other words, if you make any changes, you'd better give them back to Sistina so they can profit from them!
This means that Red Hat, SuSE, Caldera, etc. cannot include GFS without paying a license fee. My understanding of Debian's licensing policy means that it can't be included in Debian either. I was looking at GFS for a new web hosting server farm I'm building, but even using it (not selling it) would require I pay them a license fee. No thanks.
They are trying to pretend to be a part of the Open Source community, but they are not really. If someone wants to develop commercial software, I have no problem with that. However, don't try to pretend to be open (or start out open to foster community support then yank it back when the product is ready).
Your understanding is flawed. The SA units only have a single tuner and a single MPEG encoder chip. The DirecTiVo units have two tuners and no encoder chip (since they record the digital bit stream direct from the satellite).
It would be nice to have two tuners in the SA box, but there are a LOT of technical issues that would have to be worked out. It wouldn't be too difficult for straight CATV RF input, but for people with external tuners (cable boxes, satellite receivers of all types), TiVo would have to provide twice as many inputs on the back of the box (and there isn't much space for that). The setup interface would be significantly more complex (is the cable box hooked up to tuner input 2? what about the IR blaster?) for arguably little gain. Some "power users" may want dual tuners, but most of the power users already have TiVo. The target market for TiVo now is the grandmas that sit their and watch their VCR blink "12:00" all the time. How many of those are going to care about (or understand) dual tuners?
I don't know if the concrete they used this year floated, but they have in the past. I was on SGA at UAH when the concrete canoe group was asking for some funding, and they brought a bucket of water with them with a hunk of concrete floating in it. That was a little weird to see.
I've been a systems/network admin for an ISP for 5.5 years, and I've
seen that there really are a large number of "Network Administrators"
that have no idea what they are doing.
In some cases, it is not their fault. One of our customers (a
bookstore with several stores) ordered a T1 line to their "corporate
headquarters". When our installer arrived, it was to a warehouse. The
job of "network administrator" was a secondary job for someone; his
primary job was driving the forklift. Would a company ask the forklift
driver to do their accounting? Why should they ask the same person to
manage what they are now considering an important part of their business
infrastructure? As the Internet (and networking in general) "matures"
and becomes a more important of business, companies will have to realize
that they can't get away with just picking the employee that seems to
recognize a computer when you drop it on his foot and calling him the
"network guy."
Part of the reason so many ISPs either keep raising prices or go out
of business is that people expect their ISP to do their network support.
When we tell a customer that our resposibility ends at the ethernet port
of the router (because they want that T1 line cheap), they get irate.
Our choices are to try to help them, even though we don't know a thing
about their network (and because of that we may screw things up more) or
to tell them it isn't our problem (which makes them mad and may cause
them to move their service). The small "mom and pop" type ISPs can
afford to do more of this kind of help in the short run, but they can't
maintain it in the long run (been there, done that). The same thing
holds true for residential (dialup/DSL) customers. People (including
me) love to complain about the quality of most tech support groups, but
try asking an ISP how much of their revenue goes to support. You get
what you pay for.
I handle our abuse email, and we get all kinds of reports. We've had
people complain that our DNS server is attacking them on port 53 (the
DNS port), that our Akamai content
distribution servers attack them every time they go to CNN, and so on.
We had an Army network admin call us a couple of weeks ago because he
was getting flooded with reports of an attack originating from our Unix
shell account server. It turns out that someone from his network had
connected to our server via SSH. When you make an outgoing TCP
connection, a random port is chosen for your end of the connection. The
port his computer had chosen happened to be one on which some old Cisco
switches had a security hole. Every single packet this guy received (he
was connected for 4 hours) cause an alert on the Army firewall. The
network admin didn't understand what was happening, and instead of going
to the computer within his network that was the "target", he jumped on
us.
As a system admin for an ISP that uses RaQs for our shared hosted and for "Rent-A-RaQ" (really a leased server in our co-location space) service, we offer different levels of service for different customers. On our shared hosting servers, only we have the root password and we maintain the servers. When one was hacked (the first server I've had hacked in over five years of being an ISP admin), we fixed it and got it back up ASAP. However, most of out Rent-A-RaQ customers have the root password for their servers and maintain them themselves (adding additional software that we don't install on the shared hosting servers, etc.). We tell them that if they have the root password, it is their problem to maintain the software updates. We don't really have much choice, since most of them change the root password without telling us or anything. When a couple of them were hacked, we did charge for recovering the RaQ and/or assisting them in recovery.
I don't know what kind of services the ISP in this case provides, but remember, there are always two sides to an issue like this. If you have the root password (and especially if you change it), don't expect someone else to maintain the server.
Apollo 1 didn't explode - it wasn't even a launch. It was an on-the-pad test, and there was a fire in the capsule - the three astronauts were asphyxiated.
It was 19 years and 1 day between Apollo 1 and Challenger STS 51-L, so I'd be worried on January 29, 2005.
And on January 27, 1967, the first Apollo capsule caught fire during a test, killing Gus Grissom (who most likely would have been the first man to walk on the Moon), Ed White, and Roger Chaffee.
Filing a "bug report" like that is a waste of everyone's time. Bugzilla is for reporting bugs, not complaining that you don't like the release. I haven't read through the bug reports, but how many of the 200 bugs this week are not really bugs?
A lot of work went into this release. I was on the beta team for this release, and there were a bunch of people working on a lot of different things to get this as ready as possible. I'm still running one beta version on a laptop and another on my desktop at home, and both are working just fine with everything I do with only two exceptions:
The laptop has a Lucent winmodem (this wasn't my choice to buy this laptop), and the only available (binary) driver doesn't work with 2.2.16.
I've got a Voodoo3 3000 in the desktop and I installed the 3D support from the "preview" directory. Periodically (not often enough I've been able to file a useful bug report) the X server will crash after having run the screen saver for an hour or two.
Are there bugs? Yep. Has there ever been a bug free OS release? Nope.
IIRC, HP is a big customer of WireSpeed, an
embedded systems developer that was recently
bought by Red Hat. Over the last year or two
they switched over to using Linux for virtually
all of their development. It is possible that
WireSpeed wrote the software for "Print
Appliance" for HP, who probably didn't care
_what_ the box ran, just that it met their
specifications (which probably required it work
with Windows).
GNU is _not_ a complete system minus a kernel. Take a basic Linux distribution (or better yet, take a basic Linux distribution from 5-8 years ago). A lot of it is GNU, but a lot of it is not. X, virtually all the network tools (both client and server), virtually all of the common daemons (slightly important ones like init, cron, lpd), and other basic stuff (like /bin/login) were not from GNU because the GNU project did not have such. GNU had a C compiler, a partially working C library (did you ever try to use GNU libc version 1?), some basic commands like ls, grep, find, awk, sed, and emacs. The myth that GNU was complete except for a kernel is false. Only by adding other stuff (some from BSD, some from the X Consortium, some other freely available software, and some written from scratch) did it become Linux.
A good bit of the development that helped some of the GNU tools (especially the C library) get to the point they are today was spurred by Linux. H.J. Lu (and many others) did an admirable job getting the old GNU C library into a state where it could really be the C library for an operating system. Ever look at the old GNU termcap library? I did, and it did not work for a lot of cases. Since then, ncurses has been claimed by GNU. Nice things like the color extensions for ls first appeared in Linux distributions and only later were they (sometimes only grudgingly) integrated into the GNU source. I haven't looked at what makes up the HURD system; how much was written by GNU for GNU? Did they write their own telnet (or ssh) daemon? What about init and login? All the world is not emacs; a lot of people use vi (and joe and jed and pico, even if it is non-free).
Does GNU deserve credit? Yes. Should it be called GNU/Linux (or that horrid "Lignux" that RMS tried to push)? No. Development does not come out of a vacuum. Linux stands on many shoulders, and GNU is one of them. To hear RMS talk about it though, you'd think Tux is standing on the GNU's foot. The rest of the world doesn't try to tack their name on Hurd; GNU should try to build on their own (excellent) reputation without trying to latch on to Linux.
Gee, Hurd is using package tools developed originally for Linux (and C library work that was done for Linux, and compiler improvements that were driven by Linux users, and ...), so RMS should give credit where credit is due. It should be more properly called Linux/Hurd, or maybe just HurL.
case. He advised others not to travel to the US and resigned his
membership on the Usenix ALS committee, citing the DMCA.
Now, if the UK passes this treaty (with the same objectionable
provisions as the DMCA), where will he go? Is Alan going to leave the
UK?
No modification is allowed at all. According to the Debian Free Software Guidelines (which they are now applying to ALL included works, not just software), they require that modifications are allowed.
If they drop the text of the license, then they'd have to drop every package licensed under the GPL (as the license requires including a copy of the license).
Slaskware was not the first commercial distribution of Linux. Slackware
just started as a set of patches and fixes on top of SLS (Soft Landing
Software IIRC), which I believe was the first commercial Linux
distribution (but not the first distribution). Yggdrasil also had an
early release available about the time of the first public Slackware
release.
- "surrepticiously blocking": I have not run across an ISP that won't
tell you they use MAPS
- "entire IP address blocks": The MAPS RBL and RSS lists list the IPs
of individual servers, not large blocks. The only MAPS list that
lists large blocks is the DUL (Dial-Up List), which lists IP blocks
of dial-up users (voluntarily contributed by ISPs to help block
direct-to-MX spam).
- "even from entire nations": IP blocks are only somewhat assigned
according to international boundaries (and see previous entry about
large IP blocks).
- "no notice to the users": Most ISPs will announce that they use MAPS
and other anti-spam methods to their users because it shows that the
ISP is trying to do something about the spam their users hate.
- "who do not even know that their mail is not being delivered": The
typical use of the MAPS lists causes messages to be rejected, so the
sender is notified that their message was not delivered.
Also, some server admins configure their mail servers to tag
messages instead of rejecting them (so they are still delivered, but
users can filter on the tag in their mail client).
And that is just the second paragraph.Email is not protected speech, anymore than snail mail is. Senders don't have the right to force recipients to read their mail. The owner of the recipient's mail box (the US Government in the case of US snail mail) has the right to decline to deliver some types of mail. There are quite a few things that the US Post Office won't deliver (including "suspicious" packages). A package may be suspicious because it has no return address and white powder leaking out, or it may be suspicious because of where it originated (be it a post office in New Jersey or a mail server at a particular IP address).
Another comparison can be made to the telephone system. I recently added a feature on my telephone service that blocks "unknown callers" (people, usually telemarketers, that don't allow their caller-ID information to be sent). Those calls are blocked at the carrier. The US Post Office and the telephone companies are "common carriers" and have to carry most communication, but they are allowed to block some. ISPs are not common carriers; they can refuse to carry whatever they don't like.
The MAPS RBL also rarely (if ever) blocks "legitimate" mail. The servers on the RBL are the servers for large spam houses that are repeat offenders and refuse to do anything about it. The RSS list does hit some legitimate email, but not much. These are lists of irresponsible mail servers. Just as it is irresponsible to yell "fire" in a crowded theater, it is irresponsible to run a mail server that allows third party relay.
There are some other DNS based blacklists that do get more "collateral damage" (sometimes intentionally). Guess what: they are not nearly as widely used as the MAPS lists. ISPs want to deliver legitimate email, because not doing so will cause unhappy customers (or no customers). However, at the same time, customers are screaming at ISPs to get rid of the spam, so each ISP has to make up its own mind as to what steps it will follow to answer the demands of customers.
I've submitted code to some projects (like util-linux, sendmail, and GNU libtermcap) and had my ideas accepted but someone else made the change (in ways that better fit the "big picture"). Nothing on my patches page for Cistron RADIUS has been integrated into that code, but that is because Cistron RADIUS is considered "stable" and doesn't get much in the way of feature changes (new features go into FreeRADIUS). I've had patches accepted for OpenSSH, wu-ftpd, and Cyrus SASL that went right into the core code base. When I suggested a change for Cricket (which is maintained on SourceForge), I was given direct access to the CVS tree and basically told to "make it so!"
Don't give up because your changes are not accepted. Talk to the maintainers, and if it is clear that they aren't interested, put your patches up on a web page and let others know about them. If they are useful and people use them, the original maintainers may decide to pick them up. If not, that's okay too - thats one of the great things about Open Source software!
They expect to get back any changes that are made. In other words, if you make any changes, you'd better give them back to Sistina so they can profit from them!
This means that Red Hat, SuSE, Caldera, etc. cannot include GFS without paying a license fee. My understanding of Debian's licensing policy means that it can't be included in Debian either. I was looking at GFS for a new web hosting server farm I'm building, but even using it (not selling it) would require I pay them a license fee. No thanks.
They are trying to pretend to be a part of the Open Source community, but they are not really. If someone wants to develop commercial software, I have no problem with that. However, don't try to pretend to be open (or start out open to foster community support then yank it back when the product is ready).
It would be nice to have two tuners in the SA box, but there are a LOT of technical issues that would have to be worked out. It wouldn't be too difficult for straight CATV RF input, but for people with external tuners (cable boxes, satellite receivers of all types), TiVo would have to provide twice as many inputs on the back of the box (and there isn't much space for that). The setup interface would be significantly more complex (is the cable box hooked up to tuner input 2? what about the IR blaster?) for arguably little gain. Some "power users" may want dual tuners, but most of the power users already have TiVo. The target market for TiVo now is the grandmas that sit their and watch their VCR blink "12:00" all the time. How many of those are going to care about (or understand) dual tuners?
I don't know if the concrete they used this year floated, but they have in the past. I was on SGA at UAH when the concrete canoe group was asking for some funding, and they brought a bucket of water with them with a hunk of concrete floating in it. That was a little weird to see.
In some cases, it is not their fault. One of our customers (a bookstore with several stores) ordered a T1 line to their "corporate headquarters". When our installer arrived, it was to a warehouse. The job of "network administrator" was a secondary job for someone; his primary job was driving the forklift. Would a company ask the forklift driver to do their accounting? Why should they ask the same person to manage what they are now considering an important part of their business infrastructure? As the Internet (and networking in general) "matures" and becomes a more important of business, companies will have to realize that they can't get away with just picking the employee that seems to recognize a computer when you drop it on his foot and calling him the "network guy."
Part of the reason so many ISPs either keep raising prices or go out of business is that people expect their ISP to do their network support. When we tell a customer that our resposibility ends at the ethernet port of the router (because they want that T1 line cheap), they get irate. Our choices are to try to help them, even though we don't know a thing about their network (and because of that we may screw things up more) or to tell them it isn't our problem (which makes them mad and may cause them to move their service). The small "mom and pop" type ISPs can afford to do more of this kind of help in the short run, but they can't maintain it in the long run (been there, done that). The same thing holds true for residential (dialup/DSL) customers. People (including me) love to complain about the quality of most tech support groups, but try asking an ISP how much of their revenue goes to support. You get what you pay for.
I handle our abuse email, and we get all kinds of reports. We've had people complain that our DNS server is attacking them on port 53 (the DNS port), that our Akamai content distribution servers attack them every time they go to CNN, and so on.
We had an Army network admin call us a couple of weeks ago because he was getting flooded with reports of an attack originating from our Unix shell account server. It turns out that someone from his network had connected to our server via SSH. When you make an outgoing TCP connection, a random port is chosen for your end of the connection. The port his computer had chosen happened to be one on which some old Cisco switches had a security hole. Every single packet this guy received (he was connected for 4 hours) cause an alert on the Army firewall. The network admin didn't understand what was happening, and instead of going to the computer within his network that was the "target", he jumped on us.
I could go on :-), but I better stop now.
I don't know what kind of services the ISP in this case provides, but remember, there are always two sides to an issue like this. If you have the root password (and especially if you change it), don't expect someone else to maintain the server.
It was 19 years and 1 day between Apollo 1 and Challenger STS 51-L, so I'd be worried on January 29, 2005.
And on January 27, 1967, the first Apollo capsule caught fire during a test, killing Gus Grissom (who most likely would have been the first man to walk on the Moon), Ed White, and Roger Chaffee.
A lot of work went into this release. I was on the beta team for this release, and there were a bunch of people working on a lot of different things to get this as ready as possible. I'm still running one beta version on a laptop and another on my desktop at home, and both are working just fine with everything I do with only two exceptions:
Are there bugs? Yep. Has there ever been a bug free OS release? Nope.
IIRC, HP is a big customer of WireSpeed, an embedded systems developer that was recently bought by Red Hat. Over the last year or two they switched over to using Linux for virtually all of their development. It is possible that WireSpeed wrote the software for "Print Appliance" for HP, who probably didn't care _what_ the box ran, just that it met their specifications (which probably required it work with Windows).