It'll prove nothing about if unifying the two was a good idea or not.
What two? Two what?
I never intended to draw a distinction between any two things in my comment. Red Hat has not unified two of anything. They have unified the Red Hat desktop. Ximian is, AFAIK, the most popular desktop that people seek out to lay over Red Hat's default installation as of 7.3, so the question becomes: will that continue, or will Bluecurve's look&feel be compelling enough that people stick with it.
GNOME does not enter the picture, other than the side-point that Ximian is gnome-based.
The first question is: is unifying desktops via theming a good idea. The answer is an emphatic yes, but with the proviso that it's a damn hard thing to do well, and you have to deal with the egos of everyone involved (including your own).
The second question is: did Red Hat pull it off well. I think we will have to wait a few months to guage how successful it has been. Ximian's Gnome2-based system will almost certianly be out soon, and I think a good measure of how usable Red Hat's desktop is will be how many people plunk Ximian down over it.
You should be able to do floppy bootstrap install, still. You will have to go looking at the "images" directory on the CD. Of course, you'll still need a) a system with both CD and floppy in order to write the floppies to boot from and b) an IDE-CD controler to get the OS from once the floppy has booted. In theory, you can still do an NFS install off of floppy, but I'm out of my depth there, since it's been 5 years since I did that, and it was Slackware.
I'm sorry, this is getting way too complicated. Clearly, what is needed is an XML format for describing such things. Observe:
The operating system formerly known as, GNU Hurd is now:
<os derived="unix" derived="mach">
<kernel name="Hurd">
<distribution name="GNU">
<distribution name="Debian">
<contributor name="POSIX" description="threading, apis">
<contributor name="K&R" description="programminglanguage">
<contributor name="Linux" description="actually running, and proving to the world that free software can produce an OS">...
This has been asked and answered in various places, but basically, Red Hat compiles key packages (glibc, kernel, openssl) for particular processors, and uses options that allow backward compatibility for all of the rest. This way, they have a minimum of duplication on the CDs. They also take advantage of some flags that let you optimize for later processors while allowing older ones to run the code. I forget if it's -march, but they do something funky there.
Take a look at the/usr/lib/rpm/rpmrc
Now, you may ask why they would want to support ancient hardware? Well, the sad truth is that rich kids (that is to say, people who can afford a good machine) who buy computers to dual boot Linux for real work and Windows for games aren't the only people who use computers. There are many in the wealthy countries (US, Europe, Japan, etc) who need to be able to re-use old hardware and even more in the developing world. Red Hat is a great OS choice for many of these people, and as it becomes entrenched in places like South America, it becomes the choice of schools and small businesses too, which will eventually become Red Hat customers for support.
This is how the BSD licensed projects try to subtly encourage people
What you describe requires no trying and is not limited to BSD-licensed projects. It is an aspect of all open source/free software development.
So instead of using paranoid legal force like the GPL...
What on earth made you think that this was the right place for a license debate?! FWIW: in this respect the GPL and the BSD-like licenses are pretty much the same. They both give you more freedom to use/distribute the code than you had before you accepted the terms of the license.
But they still have the mir space station set as a sattelite for Earth.
Look again. It's inside the earth. However, you can trun back time (use the j key to go backwards and the k and l keys to change rate of time passage) and watch Mir "un-crash":)
I tried to do this with Apollo 11 which they also have transit data for, but I went and forgot exactly when it flew. I'll look it up in the data files at some point, and then watch the mission...
There are problems, by my gods! Have you tried selecting M33? Type "<return>M33<return>g" (make sure you turn on galaxy rendering with u and galaxy labeling with e). Now type "hc" to look back and the Milky Way. Finally, you can type "g" to take a put-star-trek-to-shame, high-speed journey back to Sol. It's just stunning!
I have a hard time talking about Mars or any other space-related topic now and not thinking about Celestia, which I installed on my Linux-based-laptop last night and spent hours using to explore the solar system, nearby stars and distant galaxies. It's a breath-taking display of what computers should be all about, and IMHO should be a tool in every grade school and high school in the country, which is then used to generate the next wave of Mars and near-solor-system exploration interest!
Check it out, and enjoy!
Re:This calls for
on
Hacker Culture
·
· Score: 3, Insightful
History loses to coloquial usage. "hacker" now has a common meaning: one who exploits flaws in computer security to gain access to computers and networks or to disable them. and a sub-culture definition among computer programmers and administrators: (a) a person who is primarily driven to explore technology by curiosity, and who indulges this curiosity in order to learn, often without regard to social convention (b) as (a), but used among computer programmers to define a type of programmer, specifically
These two sets of definitions were caused (as best I can tell) when the latter definition was used to describe Robert Morris Jr. to the popular media. Because Mr. Morris was responsible for the largest-scale computer intrusion yet measured in 1987 (the so-called "Internet Worm"), the media assumed that this term refered only to invasive and/or unauthorized "hacking", which was not true, but turned out to be too subtle a distinction to convey to the press.
The attempt, after the fact, to promulgate the term cracker to replace this mistaken definition of hacker met only limited success among those who already used hacker according to its traditional meaning.
What complicated the situation even more was the advent of the so-called "script kiddies", a sub-culture of disaffected youth who did not match the (comparitively altruistic) historical definition of hacker, but did meet the new, media-driven definition. This schism was forever imortalized in the movie, "Hackers", which besides being a terribly written movie also contained non-classic-hacker script kiddies, idealized to the level of pop heroes.
So, IMHO, when you say "hacker", you mean the media definition unless you are among a sub-culture which would recognize the classic meaning. Get over it.
Aaron Sherman - Hacker at large (and large hacker:)
Apache - not GNU. PHP - not GNU. Samba - not GNU. Sendmail - not GNU. Perl - not GNU. KDE - not GNU.
Yep. FSF claims to be the "primary developer" of the GNU/Linux system because they wrote most of the code.
The phrase "bzzzt! Thanks for playing!" comes to mind.
You mentioned a few, but let's get that list under analysis. I just happen to have a *Linux* system here. It's specifically a Red Hat Linux 7.3 system. It's not a complete install, but it's quite functional, so it should be a fair comparison of the "required parts of GNU" vs. "the required parts of Linux".
When I do an "rpm -qa" and clean up/uniquify the output to remove all of the duplicate kde, GNOME, XFree86, etc packages (I don't count XFree86 fonts seperately from XFree86, for example) I see 677 packages. Now, let's say that some of those are man-pages (which GNU was unwilling to write for years because they didn't like the format) and other non-program packages (like redhat-relase, which is just a marker), so I'll round that down to 600.
Now, I go and look at ftp.gnu.org:/gnu, and I find that there are 216 sub-directories. Most of those are packages, but some are not.
To weed that down, I check to see which ones are installed on my system. I get a little shock... 52 GNU packages are installed on my machine.
Yes, gcc was a lot of work, and a great compiler. I love it, but it's utility doesn't make up for the fact that GNU tools are a small part of a working Linux system. Hey, I've got an idea! Let's call it little-bit-of-GNU/Linux!
No wait, let me think about it <pause for a beat> YES!
You want to have as many of these projects as you can, and then over the next few years most will be shaken out. Even now, Mozilla is feeling the pressure to work on performance. Why? Because Galeon, Konqeror, Phoenix and lynx (:) are all faster on UNIX and UNIX-like systems. This forces Mozilla to evaluate its place. Do they want to drop the browser as a reference effort and just focus on the "browser-building toolkit"? If not, they need to compete on the performance level or on some other level (e.g. bring the mailer and the browser closer together and make that interaction something worth the slow-down, which it is not right now).
Mozilla is a great browser, and if Galeon weren't an even better one, I'd use it. Everyone wins because of this competition, just as everyone wins because KDE and GNOME have both worked so had to be at least as featureful and usable as eachother.
It's funny. before all this GNU/Linux sillyness, I used to make a point to explain how GNU contributed so many important pieces of software to the community, and how Linux would not be possible without a lot of the key work that Richard and others did.
It's too bad that now I feel tainted by all that hubris, and can't bring myself to mention those things any more. If someone asks, or I hear someone say something wildly innacurate about the history, I still bring it up, but GNU definitely lost a cheerleader when Richard took up this crusade.
He points out that this method of calling a full operating system distribution the same name as the operating system itself (that is, "operating system" in the classic C.S. sense, which means the kernel and to a lesser extent the support libraries) is quite unique to Linux. He is only 1/2 right.
I know of no distribution that calls itself "Linux" There is Debian GNU/Linux, Red Hat Linux, SuSE, Slackware, Yellow Dog Linux, etc. These are all "Linux systems" in the same way that BSD UNIX, System V UNIX, Solaris, HP/UX and IRIX are all "UNIX systems", named after the UNIX kernel which was written so very long ago by K&R&T at Bell Labs.
So, "Linux" is a general term in the same way that "UNIX" is a general term. It is also a specific term when used to refer to a Kernel.
The idea that we should call all of these distributions "GNU/Linux" is a suggestion that should be taken to each vendor (be they free-as-in-beer vendors or commercial vendors). Red Hat could be petitioned to call their OS Red Hat GNU/Linux, and if they wanted to, hey, more power to them. But if they don't want to, I just don't see the point in trying to force them.
Stallman also agrues that GNU/Linux is the correct term because Linux is just a completed GNU system. I disagree. I worked on GNU, though only briefly. They were talking at the time (late 80s) of not writing some of the OS themselves and instead using work that had already been done. To that end, they used X, sendmail, bind, etc.
Linux systems have done this too, but wholely independantly. These unifinished aspects of the GNU system are still unfinished, and I don't see why Stallman gets to ignore their contribution to both GNU and Linux.
I don't want to get too nit-picky. It's a long document, and an awful lot of it is reverse-speak, used to derive a certain thesis from the events, not describe the events as they actually happened. To read this document, you would think that GNU was a complete system, all except for that pesky little kernel that MIB couldn't finish without learing to actually communicate with other developers.
In reality, Linux was a long time in getting to the point that it worked well as a whole system. The GNU utilities, glibc, gcc and to a lesser extent, Emacs were all helpful. Then Linux needed init, the tools to integrate X and configure it, system installation tools, and a dizzying array of other tools are used by Linux systems. Also, Linux used existing pieces were possible, just as GNU would have. GNU was never going to have its own Windowing system, but would have used X, just as Linux does. The same is true for a large number of other tools that existed by the early 1990s, and were not GNU tools at all.
GNU created a C library and a compliler. For those two things alone, they deserve a huge pat on the back. But, to demand being cited every time someone refers to the system is too much hubris for any one project.
They aren't the ones creating newspeak, everyone who doesn't call the operating system by it's correct name is. That little bit of semantic engineering that shrtens the name to Linux is newspeak.
The OS is called Linux (not just the kernel, but the idea of taking a Linux kernel and adding MIT's Windowing system and Berkely's mailer and GNU's compiler, etc... that resulting thing regardless of minor variations between vendor is, by convention, called Linux in the same way that we call some other OS "Solaris" even though it uses a great deal of System V UNIX software). The OS has been called Linux since long before Stallman got a hair up his ass over calling it GNU/Linux. When I discuss Linux, and I want to attribute its major contributors, I usually call it BSD/GNU/MIT/Open Source in general/Linux, but that's only for "special" occasions.
GNU/Linux is what it is.
And so, how is XFree86 part of GNU/Linux? Sendmail? Wu-ftpd? Bind? Evolution? KDE?
No, it is Linux. Stallman calls it GNU/Linux and he's welcome to. I just wish he'd get it through his head that creating an "us" and "them" out of the free software world is hurtful and incompatible with his stated goals.
Also, come the 2.6 kernel, and pluggable security modules, installing stack protectors and tiered security models will be more commonplace and a lot of the stupid holes that have allowed these attacks will simply go away.
One thing that would fix a whole lot of problems is for a security model to be installed that allowed root to delegate low-port and raw-protocol access to non-root accounts.
Granted these particular worms would not have cared, but there have been many remote root exploits that happened only because a daemon needed to be root to create a low port or perform raw protocol manipulation.
Views could be a nice idea, but I've never seen then work well.
1 pre-compilation: yippee.
Well, yes and no. Take this example:
view_abc = select a from b where c > 1
Now here's a select that uses it:
select count(*) from view_abc v where v.a > 1
Ideally this will be turned into
select count(*) from b where a>1 and c>1
But in every DB I've ever seen, that's not what's going to happen. Even if it did, it would mean starting over in terms of execution strategy, and most of the benefit of pre-compilation goes out the window (parsing text is not where you'll spend your time, and if it is, you can write a stored procedure or an external app that caches a pre-compiled version of the final query you want).
2. modularization: ya only gotta write it once
In most cases, this is modularization that you want to perform through stored procedures or, better yet, in external code.
3. permissions: Why give permissions on your base tables to those pesky users?
If you're using your databae to manage this kind of permission, views are the least of your problems. Most databases (of any reasonable size) have two types of users: read-only and full access. Beyond that, your application should be managing access.
4. updatable views: kinda follows from 3, IMHO
If you've managed a production environment with updatable views, congradulations. I would think that the overhead for the developers would be huge in terms of trying ot figure out where bugs were coming from. I would avoid such a thing, if at all possible.
So, what are the downsides? Cites? Examples? Hard numbers?
In my brief experience with views, performance is about 2-3 times slower than when you construct the query yourself. This is based on using Oracle, which I admit is a bad example of just about everything, but it's what we had at the time.
Personally, I'd be happiest if MySQL never has sub-selects. When you're forced to work around the lack of sub-selects you are also forced to avoid one of the most costly and difficult-to-optmize features of modern relational databases.
If they're there in a later release, I'll probably use them, but only because I'm lazy. Views are also one of the worst pigs ever created.
Now, triggers I'm of two minds about. Simple triggered events (e.g. tbl1.col1 = f(tbl1.col2) where f is a basic, internal MySQL function) should be supported, no doubt about it. But, if what you want is to tie a program to updates, then I think an event model for external applications would be a much better way to go.
However, if you're not of the "treat the database like hardware" camp that I'm in, you'll be happy to hear this:
Internally, through a new.frm file format for table definitions, MySQL 4.0 lays the foundation for the new features of MySQL 4.1, such as nested subqueries, stored procedures, and foreign key integrity rules, which form the top of the wish list for many of our customers. Along with those, we will also include simpler additions, such as multi-table UPDATE statements.
That's from the 4.0 "in a nutshell" page. 4.0 is currently in beta, though if previous MySQL releases are any indicator, don't expect it to be out of beta right away. They're pretty fanatical about stable releases.
If you start converting now, I imagine you should be in good shape by the time 4.1 is out. Good luck!
Please note that CPANPLUS is intended to eventually be a full drop-in replacement for CPAN.pm. However, in early releases you should NOT expect complete compatibility.
For now, it's best to let people learn CPAN.pm. CPANPLUS will be fully functional soon....
This is unclear as yet. The question is, will we want to take/usr/bin/perl away and call the perl6 compiler plc or something? I don't know. We shall see.
Ok, this guy has been spamming every Perl-related posting with this CGI security stuff. Can we start modding him down until he actually takes the time to put something coherent in with the link (e.g. an explanation of its relevancy)?
I'll blow the mod point next time I have them, but would appreciate if someone else could get it for now.
You slightly over-simplify, but more importantly, you've left some things out.
Perl 6 will not have a "compatibility mode" per se (actually it will in patterns, but that's not what you were refering to); it will have a full-fledged Perl 5 compiler that will compile down to Parrot byte-code just like Perl 6 will (as will Python, Scheme and some other languages).
By its nature, it will have to know more about Perl 6's internals than the other language front-ends, but not by much. You will be able to do something like "perl5 program" and your program will run exactly as you expect, and modules will be auto-recognized (because Perl 6 does not use the "package" keyword).
There is a catch. XS modules (those that directly interface with Perl's internals in order to talk to external C or C++ libraries) may need more help. In most cases, the interface will still be available through some emulation, but some will simply have to be fixed to work with Parrot-based Perl 5.
Perl is a wonderful language, but like any it takes time to ease into, and it has its warts (both the aesthetic "ew, I hate dollar signs" warts that newbies hate and the deeper "roll your own OO is painful" blemishes). However, CPAN ends all argument, IMHO. If you aren't using CPAN, you're wasting your (company's?) time.
There are just so many amazing libraries in CPAN, I can't get over how most of what I want to do is already there, and at my fingertips. Want process management? WWW client emulation? Scientific computing functions? It's all in there, and managable via the CPAN.pm module.
Come Perl 6, CPAN (or its successor) will be even more valuable. The back-end virtual machine (Parrot) will have modules which give it access to external capabilities, and any Parrot-based language will be able to use them. You'll be able to call Perl's LWP from Python, or a scheme tree-handler from Perl. The details are all being worked on as we speak, but the basic building blocks are mostly in place already.
changes to the infrastructure can change the way you approach problems.
Yes, certainly. However, thread management has more headaches than can be hidden by the kernel and libraries easily. At least some of that overhead evidences in your userspace program. In many cases when people use threads, they're really just not thinking about their application. That's fine if performance is not a strong concern, but when it is (as evidenced by recent work in the Web server arena), threads should just be a tool in your box, along with many other techniques.
You are correct. To state that in more specific terms, threads are a "big hammer" that can be applied to the need to manage multiple resources at once. In my experience (on general purpose hardware) you can always optimize that resource management better in a single process than the kernel can by performing lightweight context switching.
Slashdot Mirror
It'll prove nothing about if unifying the two was a good idea or not.
What two? Two what?
I never intended to draw a distinction between any two things in my comment. Red Hat has not unified two of anything. They have unified the Red Hat desktop. Ximian is, AFAIK, the most popular desktop that people seek out to lay over Red Hat's default installation as of 7.3, so the question becomes: will that continue, or will Bluecurve's look&feel be compelling enough that people stick with it.
GNOME does not enter the picture, other than the side-point that Ximian is gnome-based.
The first question is: is unifying desktops via theming a good idea. The answer is an emphatic yes, but with the proviso that it's a damn hard thing to do well, and you have to deal with the egos of everyone involved (including your own).
The second question is: did Red Hat pull it off well. I think we will have to wait a few months to guage how successful it has been. Ximian's Gnome2-based system will almost certianly be out soon, and I think a good measure of how usable Red Hat's desktop is will be how many people plunk Ximian down over it.
You should be able to do floppy bootstrap install, still. You will have to go looking at the "images" directory on the CD. Of course, you'll still need a) a system with both CD and floppy in order to write the floppies to boot from and b) an IDE-CD controler to get the OS from once the floppy has booted. In theory, you can still do an NFS install off of floppy, but I'm out of my depth there, since it's been 5 years since I did that, and it was Slackware.
The operating system formerly known as, GNU Hurd is now:
-
<kernel name="Hurd">
<distribution name="GNU">
<distribution name="Debian">
<contributor name="POSIX" description="threading, apis">
<contributor name="K&R" description="programminglanguage">
<contributor name="Linux" description="actually running, and proving to the world that free software can produce an OS">
...
</os>This has been asked and answered in various places, but basically, Red Hat compiles key packages (glibc, kernel, openssl) for particular processors, and uses options that allow backward compatibility for all of the rest. This way, they have a minimum of duplication on the CDs. They also take advantage of some flags that let you optimize for later processors while allowing older ones to run the code. I forget if it's -march, but they do something funky there.
/usr/lib/rpm/rpmrc
Take a look at the
Now, you may ask why they would want to support ancient hardware? Well, the sad truth is that rich kids (that is to say, people who can afford a good machine) who buy computers to dual boot Linux for real work and Windows for games aren't the only people who use computers. There are many in the wealthy countries (US, Europe, Japan, etc) who need to be able to re-use old hardware and even more in the developing world. Red Hat is a great OS choice for many of these people, and as it becomes entrenched in places like South America, it becomes the choice of schools and small businesses too, which will eventually become Red Hat customers for support.
This is how the BSD licensed projects try to subtly encourage people
What you describe requires no trying and is not limited to BSD-licensed projects. It is an aspect of all open source/free software development.
So instead of using paranoid legal force like the GPL...
What on earth made you think that this was the right place for a license debate?! FWIW: in this respect the GPL and the BSD-like licenses are pretty much the same. They both give you more freedom to use/distribute the code than you had before you accepted the terms of the license.
Thus, your point is rather moot.
But they still have the mir space station set as a sattelite for Earth.
:)
Look again. It's inside the earth. However, you can trun back time (use the j key to go backwards and the k and l keys to change rate of time passage) and watch Mir "un-crash"
I tried to do this with Apollo 11 which they also have transit data for, but I went and forgot exactly when it flew. I'll look it up in the data files at some point, and then watch the mission...
There are problems, by my gods! Have you tried selecting M33? Type "<return>M33<return>g" (make sure you turn on galaxy rendering with u and galaxy labeling with e). Now type "hc" to look back and the Milky Way. Finally, you can type "g" to take a put-star-trek-to-shame, high-speed journey back to Sol. It's just stunning!
I have a hard time talking about Mars or any other space-related topic now and not thinking about Celestia, which I installed on my Linux-based-laptop last night and spent hours using to explore the solar system, nearby stars and distant galaxies. It's a breath-taking display of what computers should be all about, and IMHO should be a tool in every grade school and high school in the country, which is then used to generate the next wave of Mars and near-solor-system exploration interest!
Check it out, and enjoy!
History loses to coloquial usage. "hacker" now has a common meaning: one who exploits flaws in computer security to gain access to computers and networks or to disable them. and a sub-culture definition among computer programmers and administrators: (a) a person who is primarily driven to explore technology by curiosity, and who indulges this curiosity in order to learn, often without regard to social convention (b) as (a), but used among computer programmers to define a type of programmer, specifically
These two sets of definitions were caused (as best I can tell) when the latter definition was used to describe Robert Morris Jr. to the popular media. Because Mr. Morris was responsible for the largest-scale computer intrusion yet measured in 1987 (the so-called "Internet Worm"), the media assumed that this term refered only to invasive and/or unauthorized "hacking", which was not true, but turned out to be too subtle a distinction to convey to the press.
The attempt, after the fact, to promulgate the term cracker to replace this mistaken definition of hacker met only limited success among those who already used hacker according to its traditional meaning.
What complicated the situation even more was the advent of the so-called "script kiddies", a sub-culture of disaffected youth who did not match the (comparitively altruistic) historical definition of hacker, but did meet the new, media-driven definition. This schism was forever imortalized in the movie, "Hackers", which besides being a terribly written movie also contained non-classic-hacker script kiddies, idealized to the level of pop heroes.
So, IMHO, when you say "hacker", you mean the media definition unless you are among a sub-culture which would recognize the classic meaning. Get over it.
Aaron Sherman - Hacker at large (and large hacker:)
Actually TiVo runs Linux, so yes there is a fair amount of GNU software.
PHP - not GNU.
Samba - not GNU.
Sendmail - not GNU.
Perl - not GNU.
KDE - not GNU.
Yep. FSF claims to be the "primary developer" of the GNU/Linux system because they wrote most of the code.
The phrase "bzzzt! Thanks for playing!" comes to mind.
You mentioned a few, but let's get that list under analysis. I just happen to have a *Linux* system here. It's specifically a Red Hat Linux 7.3 system. It's not a complete install, but it's quite functional, so it should be a fair comparison of the "required parts of GNU" vs. "the required parts of Linux".
When I do an "rpm -qa" and clean up/uniquify the output to remove all of the duplicate kde, GNOME, XFree86, etc packages (I don't count XFree86 fonts seperately from XFree86, for example) I see 677 packages. Now, let's say that some of those are man-pages (which GNU was unwilling to write for years because they didn't like the format) and other non-program packages (like redhat-relase, which is just a marker), so I'll round that down to 600.
Now, I go and look at ftp.gnu.org:/gnu, and I find that there are 216 sub-directories. Most of those are packages, but some are not.
To weed that down, I check to see which ones are installed on my system. I get a little shock... 52 GNU packages are installed on my machine.
That's it.
I check again.
And again.
Nope, that's it!
Yes, gcc was a lot of work, and a great compiler. I love it, but it's utility doesn't make up for the fact that GNU tools are a small part of a working Linux system. Hey, I've got an idea! Let's call it little-bit-of-GNU/Linux!
Yes.
No wait, let me think about it <pause for a beat> YES!
You want to have as many of these projects as you can, and then over the next few years most will be shaken out. Even now, Mozilla is feeling the pressure to work on performance. Why? Because Galeon, Konqeror, Phoenix and lynx (:) are all faster on UNIX and UNIX-like systems. This forces Mozilla to evaluate its place. Do they want to drop the browser as a reference effort and just focus on the "browser-building toolkit"? If not, they need to compete on the performance level or on some other level (e.g. bring the mailer and the browser closer together and make that interaction something worth the slow-down, which it is not right now).
Mozilla is a great browser, and if Galeon weren't an even better one, I'd use it. Everyone wins because of this competition, just as everyone wins because KDE and GNOME have both worked so had to be at least as featureful and usable as eachother.
It's funny. before all this GNU/Linux sillyness, I used to make a point to explain how GNU contributed so many important pieces of software to the community, and how Linux would not be possible without a lot of the key work that Richard and others did.
It's too bad that now I feel tainted by all that hubris, and can't bring myself to mention those things any more. If someone asks, or I hear someone say something wildly innacurate about the history, I still bring it up, but GNU definitely lost a cheerleader when Richard took up this crusade.
He points out that this method of calling a full operating system distribution the same name as the operating system itself (that is, "operating system" in the classic C.S. sense, which means the kernel and to a lesser extent the support libraries) is quite unique to Linux. He is only 1/2 right.
I know of no distribution that calls itself "Linux" There is Debian GNU/Linux, Red Hat Linux, SuSE, Slackware, Yellow Dog Linux, etc. These are all "Linux systems" in the same way that BSD UNIX, System V UNIX, Solaris, HP/UX and IRIX are all "UNIX systems", named after the UNIX kernel which was written so very long ago by K&R&T at Bell Labs.
So, "Linux" is a general term in the same way that "UNIX" is a general term. It is also a specific term when used to refer to a Kernel.
The idea that we should call all of these distributions "GNU/Linux" is a suggestion that should be taken to each vendor (be they free-as-in-beer vendors or commercial vendors). Red Hat could be petitioned to call their OS Red Hat GNU/Linux, and if they wanted to, hey, more power to them. But if they don't want to, I just don't see the point in trying to force them.
Stallman also agrues that GNU/Linux is the correct term because Linux is just a completed GNU system. I disagree. I worked on GNU, though only briefly. They were talking at the time (late 80s) of not writing some of the OS themselves and instead using work that had already been done. To that end, they used X, sendmail, bind, etc.
Linux systems have done this too, but wholely independantly. These unifinished aspects of the GNU system are still unfinished, and I don't see why Stallman gets to ignore their contribution to both GNU and Linux.
I don't want to get too nit-picky. It's a long document, and an awful lot of it is reverse-speak, used to derive a certain thesis from the events, not describe the events as they actually happened. To read this document, you would think that GNU was a complete system, all except for that pesky little kernel that MIB couldn't finish without learing to actually communicate with other developers.
In reality, Linux was a long time in getting to the point that it worked well as a whole system. The GNU utilities, glibc, gcc and to a lesser extent, Emacs were all helpful. Then Linux needed init, the tools to integrate X and configure it, system installation tools, and a dizzying array of other tools are used by Linux systems. Also, Linux used existing pieces were possible, just as GNU would have. GNU was never going to have its own Windowing system, but would have used X, just as Linux does. The same is true for a large number of other tools that existed by the early 1990s, and were not GNU tools at all.
GNU created a C library and a compliler. For those two things alone, they deserve a huge pat on the back. But, to demand being cited every time someone refers to the system is too much hubris for any one project.
They aren't the ones creating newspeak, everyone who doesn't call the operating system by it's correct name is. That little bit of semantic engineering that shrtens the name to Linux is newspeak.
The OS is called Linux (not just the kernel, but the idea of taking a Linux kernel and adding MIT's Windowing system and Berkely's mailer and GNU's compiler, etc... that resulting thing regardless of minor variations between vendor is, by convention, called Linux in the same way that we call some other OS "Solaris" even though it uses a great deal of System V UNIX software). The OS has been called Linux since long before Stallman got a hair up his ass over calling it GNU/Linux. When I discuss Linux, and I want to attribute its major contributors, I usually call it BSD/GNU/MIT/Open Source in general/Linux, but that's only for "special" occasions.
GNU/Linux is what it is.
And so, how is XFree86 part of GNU/Linux? Sendmail? Wu-ftpd? Bind? Evolution? KDE?
No, it is Linux. Stallman calls it GNU/Linux and he's welcome to. I just wish he'd get it through his head that creating an "us" and "them" out of the free software world is hurtful and incompatible with his stated goals.
Also, come the 2.6 kernel, and pluggable security modules, installing stack protectors and tiered security models will be more commonplace and a lot of the stupid holes that have allowed these attacks will simply go away.
One thing that would fix a whole lot of problems is for a security model to be installed that allowed root to delegate low-port and raw-protocol access to non-root accounts.
Granted these particular worms would not have cared, but there have been many remote root exploits that happened only because a daemon needed to be root to create a low port or perform raw protocol manipulation.
1 pre-compilation: yippee.
Well, yes and no. Take this example:
- view_abc = select a from b where c > 1
Now here's a select that uses it:- select count(*) from view_abc v where v.a > 1
Ideally this will be turned into- select count(*) from b where a>1 and c>1
But in every DB I've ever seen, that's not what's going to happen. Even if it did, it would mean starting over in terms of execution strategy, and most of the benefit of pre-compilation goes out the window (parsing text is not where you'll spend your time, and if it is, you can write a stored procedure or an external app that caches a pre-compiled version of the final query you want).2. modularization: ya only gotta write it once
In most cases, this is modularization that you want to perform through stored procedures or, better yet, in external code.
3. permissions: Why give permissions on your base tables to those pesky users?
If you're using your databae to manage this kind of permission, views are the least of your problems. Most databases (of any reasonable size) have two types of users: read-only and full access. Beyond that, your application should be managing access.
4. updatable views: kinda follows from 3, IMHO
If you've managed a production environment with updatable views, congradulations. I would think that the overhead for the developers would be huge in terms of trying ot figure out where bugs were coming from. I would avoid such a thing, if at all possible.
So, what are the downsides? Cites? Examples? Hard numbers?
In my brief experience with views, performance is about 2-3 times slower than when you construct the query yourself. This is based on using Oracle, which I admit is a bad example of just about everything, but it's what we had at the time.
If they're there in a later release, I'll probably use them, but only because I'm lazy. Views are also one of the worst pigs ever created.
Now, triggers I'm of two minds about. Simple triggered events (e.g. tbl1.col1 = f(tbl1.col2) where f is a basic, internal MySQL function) should be supported, no doubt about it. But, if what you want is to tie a program to updates, then I think an event model for external applications would be a much better way to go.
However, if you're not of the "treat the database like hardware" camp that I'm in, you'll be happy to hear this:That's from the 4.0 "in a nutshell" page. 4.0 is currently in beta, though if previous MySQL releases are any indicator, don't expect it to be out of beta right away. They're pretty fanatical about stable releases.
If you start converting now, I imagine you should be in good shape by the time 4.1 is out. Good luck!
For now, it's best to let people learn CPAN.pm. CPANPLUS will be fully functional soon....
This is unclear as yet. The question is, will we want to take /usr/bin/perl away and call the perl6 compiler plc or something? I don't know. We shall see.
Ok, this guy has been spamming every Perl-related posting with this CGI security stuff. Can we start modding him down until he actually takes the time to put something coherent in with the link (e.g. an explanation of its relevancy)?
I'll blow the mod point next time I have them, but would appreciate if someone else could get it for now.
You slightly over-simplify, but more importantly, you've left some things out.
Perl 6 will not have a "compatibility mode" per se (actually it will in patterns, but that's not what you were refering to); it will have a full-fledged Perl 5 compiler that will compile down to Parrot byte-code just like Perl 6 will (as will Python, Scheme and some other languages).
By its nature, it will have to know more about Perl 6's internals than the other language front-ends, but not by much. You will be able to do something like "perl5 program " and your program will run exactly as you expect, and modules will be auto-recognized (because Perl 6 does not use the "package" keyword).
There is a catch. XS modules (those that directly interface with Perl's internals in order to talk to external C or C++ libraries) may need more help. In most cases, the interface will still be available through some emulation, but some will simply have to be fixed to work with Parrot-based Perl 5.
Perl is a wonderful language, but like any it takes time to ease into, and it has its warts (both the aesthetic "ew, I hate dollar signs" warts that newbies hate and the deeper "roll your own OO is painful" blemishes). However, CPAN ends all argument, IMHO. If you aren't using CPAN, you're wasting your (company's?) time.
There are just so many amazing libraries in CPAN, I can't get over how most of what I want to do is already there, and at my fingertips. Want process management? WWW client emulation? Scientific computing functions? It's all in there, and managable via the CPAN.pm module.
Come Perl 6, CPAN (or its successor) will be even more valuable. The back-end virtual machine (Parrot) will have modules which give it access to external capabilities, and any Parrot-based language will be able to use them. You'll be able to call Perl's LWP from Python, or a scheme tree-handler from Perl. The details are all being worked on as we speak, but the basic building blocks are mostly in place already.
changes to the infrastructure can change the way you approach problems.
Yes, certainly. However, thread management has more headaches than can be hidden by the kernel and libraries easily. At least some of that overhead evidences in your userspace program. In many cases when people use threads, they're really just not thinking about their application. That's fine if performance is not a strong concern, but when it is (as evidenced by recent work in the Web server arena), threads should just be a tool in your box, along with many other techniques.
You are correct. To state that in more specific terms, threads are a "big hammer" that can be applied to the need to manage multiple resources at once. In my experience (on general purpose hardware) you can always optimize that resource management better in a single process than the kernel can by performing lightweight context switching.