I should find some reference material for this, but I'm too lazy.
My understanding is that in the past the parties chose their own candidates without the help of the state governments. This generally meant that a few powerful members of the party -- the elite or rich -- chose their candidate in what was seen by the public as secret, corrupt "smoke-filled rooms". Especially in a two-party system, this bothered the voting public, so reforms were passed to help make sure there was a fair and open system for the parties' to choose their candidates.
The chapter suggests that the story about the Florida voter registration scrub mixups didn't run in the U.S. This is simply incorrect. I certainly had heard about it quite a bit, and not from the venerable BBC. By the way, the BBC's "reporting of the news is suddenly in disrepute".
It also seems to suggest that purging of voter registration lists is a corrupt idea, when in fact a quick search of the news reveals that many precincts in the U.S. are struggling with problems of convited felons or dead people voting.
The 2000 elections in Florida deserve a thoughtful, informed examination, while this book seems to provide more of a frenzied, mis-informed opinion.
I got a one4all non-learning remote from Wal-Mart for about $10 and have been completely satisfied. It comes with a booklet that allows you to easily program it to control a wide variety of common TVs, VCRs, DVDs, etc. It also allows for custom programming of individual buttons, so if you want to build your own keymap if basically allows that. Even better, their email tech support will send you undocumented codes for even more units than are described in the booklet. It includes a couple "macro" buttons that allow you to program a series of other button-presses so that you can, for example, turn on all your equipment with one button. It has a pair of infrared LEDs which it apparently uses to provide a strong signal across a wide angle.
The button layout isn't the most ergonomic, but for $10 I was quite impressed. It worked much better than the other (slightly less-cheap) RCA "universal" remotes that I have tried.
Judd Gregg is my senator, and I agree with him on many issues. When I heard his stance on this (which he apparently held since before I was his constituent), I immediately wrote, printed, and mailed a letter on the topic.
I got a response just this week, but it's not clear from the (I assume) canned response whether or not anyone in his office actually recorded my position on the matter.
Oh, well. I'm glad at least one proponent of this ridiculous position is backing off a bit.
Re:Not bad, but not as big as one might think.
on
NYSE Goes To Linux
·
· Score: 1
No need to speculate:
SIAC's Artmail applications previously ran on Sun Microsystems Inc. (SUNW) servers that used Unix. But they will now run on IBM Linux servers linked to an IBM mainframe system.
Some people have been saying "Unix is dead", and looking to MS's "New Technology" as being an improvement. This just shows, to those companies that are willing to see, the benefits of using a standardized OS like Unix -- you have options. If they had been using NT, they'd be a good deal more stuck than they are. Smart organizations can learn from this and choose to avoid NT.
You left out the solution SourceForge.net is working on, called Trove, or simply the Software Map. It contains fields for Development Status, Environment, Intended Audience, License, Operating System, Programming Language, Topic, and Description, and is centrally served from http://sourceforge.net/softwarema p/trove_list.php.
Several of the categories are even hierarchical, which helps validate the values used. Another benefit is that if the license is open 'enough', you can host your web page and downloads at SourceForge, at which point it will help you track versions and release notes.
Wow -- that sounds like I'm a SourceForge PR person. Please understand that I'm not necessarily advocating them as the best solution -- I think freshmeat and lsm are extremely valuable. I just wanted to make sure the SourceForge solution was mentioned.
There's much more detailed information from IBM Research than was included in the press release. It's interesting that apparently Los Alamos has already developed a 7-qubit computer, it's just that they haven't used it to solve a real math problem yet.
As usual, Slashdot comments are heavy on hyperbole, light on fact. To help swing the balance towards rationality, here are some links to the actual bill that (I think) Katz is referring to.
I've put web sites in CVS -- HTML isn't quite programming.;-)
This is particularly useful with SourceForge, where the main way to get your code up to the server is via CVS, but the main way to get your web pages up is via FTP. The moment you have more than one person fixing things on the site at once, FTP hurts
So I put the web pages in CVS, and added a CGI link that updates the live pages based on the latest version in CVS. All sorts of benefits...
I have no idea if this type of post has any positive impact on message scores, but I followed the above link, and I must say the Street Performer Protocol is extremely interesting. And the essay is well-written, to boot. People need to read this thing -- this message needs to have a Score: 5.
I just put a couple MP3's up, and forgot about 'em. Last week, I got a fan letter.
I think your statements shows how weak his point about young artists is. I don't doubt that there was only 1 non-label artist download on Napster in 48 hours, because Napster is not a good forum for finding artists you haven't heard of. Try mp3.com, instead.
But his point was that young artists need record labels in order to be heard. This is so wrong. What are your chances of getting signed by a record label? From your comments, I would bet you would agree they are slim. But by circumventing classic (archaic) record labels you got heard, which is more than any record label would have done for you.
So he is wrong to think that classic labels are needed by young artists. And he said himself that as soon as they get out from under their currect contract with a record label, that they will be looking at internet distribution ideas. This obviously spells doom for classic labels.
Other than that point, however, I think he was surprisingly articulate and I can certainly understand his position. Whether or not trading music should be illegal, it currently is, and by law, Metallica should be able to seek some kind of relief. Whether or not what Napster as a company is doing is illegal or not remains to be seen...
BTW, I kept referring to 'classic' record labels, because places like mp3.com and labels like GoodNoise "get it", and fulfill some of the roles of record labels that are still needed.
Interesting! I'm not sure I understand why you would use PHP if you are going to put all the PHP in a separate file... on the other hand, I know rather little about PHP, so perhaps you can enlighten me.
After a quick look through the documentation for FastTemplate (And the cacheable version) I was surprised to see there was no support for loops. Did I miss it? How do you handle building tables of response data without putting the table tags inside your code?
HTML::Template has severely constrained forms of variable replacement, if statements, and loops. It's difficult to strike a balance between flexibility of the template and keeping program logic out of it. Even with a template solution it is possible to put too much complexity into the HTML, but templates do help greatly. FYI, HTML::Template has a cacheing mechanism that works beautifully with mod_perl, allowing all of the code and template data to reside in memory instead of on disk.
I've said it before, and I will say it again: Do everything you can to separate the program logic (the code) and the HTML layout.
Why:
The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.
How:
Avoid those seductive solutions that encourage embedding code in HTML. This includes PHP, EmbPerl, ASP, and others (Zope?). Since this question is about CGI, you're already on the right track to avoiding these.
If you must use one of the above, work very hard to separate the code anyway. Put as much of your code into separate files as you can, and then just "#include" (or equivalent) the appropriate HTML file.
Use technologies that encourage this separation. My current favorite is HTML::Template, a perl module. This in itself may be a good enough reason to recommend perl as a first choice for most CGIs.
So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.
I've said it before, and I'll say it again: Do everything you can to separate the program logic (the code) and the HTML layout.
Why:
The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.
How:
Avoid those seductive solutions that encourage embedding code in HTML. This includes PHP, EmbPerl, ASP, and others (Zope?). Since this question is about CGI, you're already on the right track to avoiding these.
If you must use one of the above, work very hard to separate the code anyway. Put as much of your code into separate files as you can, and then just "#include" (or equivalent) the appropriate HTML file.
Use technologies that encourage this separation. My current favorite is HTML::Template, a perl module. This in itself may be a good enough reason to recommend perl as a first choice for most CGIs.
So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.
I've enjoyed every book of yours I've ever read, and I own several copies of many of them (one to read, one to loan, etc.)
So when I discovered (years ago) that you had written an episode for the BBC series Dr. Who, my emotional reaction was matched only by my dispair when I found that it was never aired.
So now the question: Did you indeed write this rumoured episode? What was your connection with Dr. Who before and after? What wasyour reaction to the episode not being aired? Have you written episodes for other TV series'?
Point taken -- I should be less confident. In fact, I was already, but being in a sort of Slashdot swagger mode, I felt the need to emote extremism. *sigh* Ah, well.
But this wasn't my main point. I will concede that 1) mutt has more holes that I'm aware of, and 2) my system is suseptible to much more than just strict "Melissa-style" viri. My main point, however, was how tempting it is to build holes into higher-level apps. I suspect that security is a significant concern in most open-source network and operating system projects. But I'm afraid that high-level application projects, such as Office clones, tend to not worry about security much. It's for this reason that I bothered posting at all -- we need to make sure that newbie-targetted "productivity" apps don't come with huge holes built in.
Heh. I wasn't slamming RedHat. Obviously I didn't make myself clear enough.
Being root most of the time while using a unix system is a Bad Thing. Having a unix system with only a root user (and no 'normal' users) is a Very Bad Thing.
I have installed both RedHat 6.1 and RedHat 6.2 beta a couple of times each in the last few months. Therefore I'm quite aware of how the installation procedure goes. As I said in my last post, RedHat makes it unhappy for a newbie user to do the Bad Things named in the above paragraph.
This means that I am happy about what RedHat has done with their installation procedure -- I think it is a Good Thing.
This describes the typical Unix situation, which is not the typical Linux situation. There, more people have installed their own system and have root priviliges.
This is repeated frequently, but does anyone have proof? The most "typical" installation, especially for newbies, is RedHat, I believe. RedHat's installation procedure makes it difficult to get started without creating a normal user account, and makes it uncomfortable to use a root account for normal work. I don't have any proof that Linux installations are as often or more often set up correctly than most Unices, but I don't have much reason to believe the contrary.
I am still afraid that I come into a Makefile someday that holds the line: install: rm -rf / Is this not a virus?
Your example is in no way self-propogating. It is at most a Trojan horse, not a virus. From the Jargon file:
virus n. A cracker program that searches out other programs and `infects' them by embedding a copy of itself in them
This article highlights a significant point about the type of applications that are popular in the free Unices. For example, my favorite email client, mutt, has absolutely no chance of propogating a Melissa-style virus.
However there is no guarantee this will always be the case. As a programmer I appreciate the apps I use having the ability to be scripted, and this is the first step down a dangerous path. My text and graphics editors, vim and gimp, both have built-in scripting languages, which is the same feature that has made MSWindows office apps so vulnerable to viri.
I think the important distinction is that none of the apps I use under Linux look for script code in their documents. This means I can't send you a gimp image with a little plug-in to help you make your own similar image. I can't send you a text file with special scripted abilities for vim as I can with MS Word. If I want to give you these scripted capabilities, I must send a seperate file that you must treat differently than a normal document file. This is the key point, and we should keep this in mind when adding features to any applications that we work on.
The danger is not as distant as you might think. The power and ease-of-use provided by this sort of feature makes it difficult to resist. For example, vim allows a special line to be embedded in a text file that gives it direction on how to display the text (tab settings and such). As long the vim group is very, very careful to make sure that there is no way to drop into the full-featured scripting language through this feature, we are still safe, but this is a tricky line to walk.
Well, maybe I didn't tell you, but I predicted this. It's only a matter of time until we see the same thing for gtk/gnome.
I figured this would happen once I saw what KDE and gnome were trying to do, namely isolate applications from X completely. Older apps communicate with graphics hardware via X. This meant that graphics hardware could be swapped in and out (and even across the network!). But now both KDE and gnome (with the help of GTK and QT, respecively) have become a complete layer between apps and X. This means it should be possible for KDE and gnome to completely skip X, and go straight to the hardware. The advent of the Linux frame buffer makes this even easier.
There were hints of this already in projects like the now defunct Harmony (FreeQT) in how it handled TrueType fonts.
As others have said, choice is great. It isn't (yet) time for X to die completely, being able to skip the rather large and complex called Xwindows will often be a great boon.
I hope that at some point, all gnome and KDE apps will be run-time (or maybe shared-link time, which amounts to the same thing) switchable between framebuffer and X. Run the app, and if the DISPLAY is local, skip X, otherwise be an X client....or something like that, but now I'm just rambling.
Hopefully I can get my questions answered without starting a flamewar. I guess we'll see...
Slackware was the first Linux distribution that I ever used. I helped administrate a small- to medium-sized unix network that included a small pile of Slackware Linux machines (along with some Sparcs, some Sun 3/60s, some Alphas, etc.). It was fine. I had no complaints, and it's the distribution that got me hooked on Unix in general and Linux in particular.
Then Debian and RedHat arrived, and I realized how out-of-control things had been under Slackware (and also Solaris and SunOS). The ability to have a tool justify the existance of every file installed on my system was amazing from a sysadmin's viewpoint. And more than that, I could find out what other programs depended on it. This was wonderful, especially for shared libraries.
Because of this experience, I've never really looked back at Slackware. But is it true that Slaskware now has some sort of package management? I must admit I don't really like the convolutions built into the RedHat configuration files -- does Slackware still do this better? Will Slackware warn me if I try to uninstall some part of the system that some other part depends on? Can I tell Slackware that it isn't allowed to install over a particular file (because I've done something special with it?)
These are the reasons I stopped using Slackware. This in no way decreases how grateful I am to Patrick, or how glad I am that there is still a minimalistic, tgz based Linux distribution.
I heartily disagree. I hate having to know the area code before I can use the standard 555-1212 information line here in the US. What you are suggesting would force the same sort of stucture on site names.
Why should I have to know in which country an organization is based in order to guess their URL? Should we then go down to individual states and provinces? Then instead of the clear, unambiguous slashdot.org, you get the silly slashdot.org.somestate.us. And what if they move? I'm rambling now, but my point is that the internet has the potential to seperate us from awkward physical boundaries, and you are advocating adopting those same boundaries.
Much preferrable would be your first suggestion -- a name heirarchy based on purpose or industry of the registering entity.
ISPs will jump in and shovel money at AOL faster than individual subscribers would. More instant capital can't hurt.
More capital means more infrastruture sooner. There are still many areas of the country that don't have cable internet access. First-to-market in these areas is still going to mean a lot of cash.
Multiple companies depending on their cable infrastructure means a more robust business model -- less suseptible to consumer-level price fluctuations, less vulnerable to Congressional bullying.
I would never recommend depending on the good will of a corporation, but I think in there are enough selfish reasons for AOL to do this that we can reasonable expect it to happen.
What makes you so certain the nVidia drivers will be closed? Their current set of drivers are available free for download, even in source form. And they claim that they are working with Precision Insight, DRI, and integrating with XFree86.
I agree that Linux seems like somewhat of a poor fit for a PDA. Linux is designed around some hardware assumptions that just aren't true on a PDA (large slow disk + small fast RAM, for example).
On the other hand, PalmOS is closed. Oops.
So what about something like eCos? It's an Open Source Operating System from a well-known company with a decent track record, both technically and license-wise. Does anyone know how well it would work on a PDA? Is there such a project going on already?
Slashdot Mirror
I should find some reference material for this, but I'm too lazy.
My understanding is that in the past the parties chose their own candidates without the help of the state governments. This generally meant that a few powerful members of the party -- the elite or rich -- chose their candidate in what was seen by the public as secret, corrupt "smoke-filled rooms". Especially in a two-party system, this bothered the voting public, so reforms were passed to help make sure there was a fair and open system for the parties' to choose their candidates.
It also seems to suggest that purging of voter registration lists is a corrupt idea, when in fact a quick search of the news reveals that many precincts in the U.S. are struggling with problems of convited felons or dead people voting.
The 2000 elections in Florida deserve a thoughtful, informed examination, while this book seems to provide more of a frenzied, mis-informed opinion.
I got a one4all non-learning remote from Wal-Mart for about $10 and have been completely satisfied. It comes with a booklet that allows you to easily program it to control a wide variety of common TVs, VCRs, DVDs, etc. It also allows for custom programming of individual buttons, so if you want to build your own keymap if basically allows that. Even better, their email tech support will send you undocumented codes for even more units than are described in the booklet. It includes a couple "macro" buttons that allow you to program a series of other button-presses so that you can, for example, turn on all your equipment with one button. It has a pair of infrared LEDs which it apparently uses to provide a strong signal across a wide angle.
The button layout isn't the most ergonomic, but for $10 I was quite impressed. It worked much better than the other (slightly less-cheap) RCA "universal" remotes that I have tried.
Judd Gregg is my senator, and I agree with him on many issues. When I heard his stance on this (which he apparently held since before I was his constituent), I immediately wrote, printed, and mailed a letter on the topic.
I got a response just this week, but it's not clear from the (I assume) canned response whether or not anyone in his office actually recorded my position on the matter.
Oh, well. I'm glad at least one proponent of this ridiculous position is backing off a bit.
You left out the solution SourceForge.net is working on, called Trove, or simply the Software Map. It contains fields for Development Status, Environment, Intended Audience, License, Operating System, Programming Language, Topic, and Description, and is centrally served from http://sourceforge.net/softwarema p/trove_list.php.
Several of the categories are even hierarchical, which helps validate the values used. Another benefit is that if the license is open 'enough', you can host your web page and downloads at SourceForge, at which point it will help you track versions and release notes.
Wow -- that sounds like I'm a SourceForge PR person. Please understand that I'm not necessarily advocating them as the best solution -- I think freshmeat and lsm are extremely valuable. I just wanted to make sure the SourceForge solution was mentioned.
--Chouser
There's much more detailed information from IBM Research than was included in the press release. It's interesting that apparently Los Alamos has already developed a 7-qubit computer, it's just that they haven't used it to solve a real math problem yet.
--Chouser
As usual, Slashdot comments are heavy on hyperbole, light on fact. To help swing the balance towards rationality, here are some links to the actual bill that (I think) Katz is referring to.
Amendment 3610 to H.R. 4577 as proposed by Senator McCain
Vote 149 - amendment agreed to
Amendment 3635 to H.R. 4577 as proposed by Senator Santorum
Vote 150 - amendment agreed to
Some discussion in the Senate about the two amendments (search for "Internet")
I think this is the final version:
H.R. 4577, TITLE VI--CHILDREN'S INTERNET PROTECTION
Full text of H.R. 4577--FY 2001 Labor, Health and Human Services, and Education Appropriations bill
Vote 273 in the House - passed
Vote 171 in the Senate - passed
--Chouser
I've put web sites in CVS -- HTML isn't quite programming. ;-)
This is particularly useful with SourceForge, where the main way to get your code up to the server is via CVS, but the main way to get your web pages up is via FTP. The moment you have more than one person fixing things on the site at once, FTP hurts
So I put the web pages in CVS, and added a CGI link that updates the live pages based on the latest version in CVS. All sorts of benefits...
--Chouser
I have no idea if this type of post has any positive impact on message scores, but I followed the above link, and I must say the Street Performer Protocol is extremely interesting. And the essay is well-written, to boot. People need to read this thing -- this message needs to have a Score: 5.
--Chouser
I just put a couple MP3's up, and forgot about 'em. Last week, I got a fan letter.
I think your statements shows how weak his point about young artists is. I don't doubt that there was only 1 non-label artist download on Napster in 48 hours, because Napster is not a good forum for finding artists you haven't heard of. Try mp3.com, instead.
But his point was that young artists need record labels in order to be heard. This is so wrong. What are your chances of getting signed by a record label? From your comments, I would bet you would agree they are slim. But by circumventing classic (archaic) record labels you got heard, which is more than any record label would have done for you.
So he is wrong to think that classic labels are needed by young artists. And he said himself that as soon as they get out from under their currect contract with a record label, that they will be looking at internet distribution ideas. This obviously spells doom for classic labels.
Other than that point, however, I think he was surprisingly articulate and I can certainly understand his position. Whether or not trading music should be illegal, it currently is, and by law, Metallica should be able to seek some kind of relief. Whether or not what Napster as a company is doing is illegal or not remains to be seen...
BTW, I kept referring to 'classic' record labels, because places like mp3.com and labels like GoodNoise "get it", and fulfill some of the roles of record labels that are still needed.
--Chouser
Interesting! I'm not sure I understand why you would use PHP if you are going to put all the PHP in a separate file... on the other hand, I know rather little about PHP, so perhaps you can enlighten me.
After a quick look through the documentation for FastTemplate (And the cacheable version) I was surprised to see there was no support for loops. Did I miss it? How do you handle building tables of response data without putting the table tags inside your code?
HTML::Template has severely constrained forms of variable replacement, if statements, and loops. It's difficult to strike a balance between flexibility of the template and keeping program logic out of it. Even with a template solution it is possible to put too much complexity into the HTML, but templates do help greatly. FYI, HTML::Template has a cacheing mechanism that works beautifully with mod_perl, allowing all of the code and template data to reside in memory instead of on disk.
--Chouser
I've said it before, and I will say it again: Do everything you can to separate the program logic (the code) and the HTML layout.
Why:- The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
- If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
- If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
- Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
- Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.
How:So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.
--Chouser
I've said it before, and I'll say it again: Do everything you can to separate the program logic (the code) and the HTML layout.
Why:- The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
- If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
- If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
- Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
- Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.
How:So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.
--Chouser
So when I discovered (years ago) that you had written an episode for the BBC series Dr. Who, my emotional reaction was matched only by my dispair when I found that it was never aired.
So now the question: Did you indeed write this rumoured episode? What was your connection with Dr. Who before and after? What wasyour reaction to the episode not being aired? Have you written episodes for other TV series'?
Thanks!
--Chouser
--Chouser
But this wasn't my main point. I will concede that 1) mutt has more holes that I'm aware of, and 2) my system is suseptible to much more than just strict "Melissa-style" viri. My main point, however, was how tempting it is to build holes into higher-level apps. I suspect that security is a significant concern in most open-source network and operating system projects. But I'm afraid that high-level application projects, such as Office clones, tend to not worry about security much. It's for this reason that I bothered posting at all -- we need to make sure that newbie-targetted "productivity" apps don't come with huge holes built in.
--Chouser
Being root most of the time while using a unix system is a Bad Thing. Having a unix system with only a root user (and no 'normal' users) is a Very Bad Thing.
I have installed both RedHat 6.1 and RedHat 6.2 beta a couple of times each in the last few months. Therefore I'm quite aware of how the installation procedure goes. As I said in my last post, RedHat makes it unhappy for a newbie user to do the Bad Things named in the above paragraph.
This means that I am happy about what RedHat has done with their installation procedure -- I think it is a Good Thing.
--Chouser
--Chouser
However there is no guarantee this will always be the case. As a programmer I appreciate the apps I use having the ability to be scripted, and this is the first step down a dangerous path. My text and graphics editors, vim and gimp, both have built-in scripting languages, which is the same feature that has made MSWindows office apps so vulnerable to viri.
I think the important distinction is that none of the apps I use under Linux look for script code in their documents. This means I can't send you a gimp image with a little plug-in to help you make your own similar image. I can't send you a text file with special scripted abilities for vim as I can with MS Word. If I want to give you these scripted capabilities, I must send a seperate file that you must treat differently than a normal document file. This is the key point, and we should keep this in mind when adding features to any applications that we work on.
The danger is not as distant as you might think. The power and ease-of-use provided by this sort of feature makes it difficult to resist. For example, vim allows a special line to be embedded in a text file that gives it direction on how to display the text (tab settings and such). As long the vim group is very, very careful to make sure that there is no way to drop into the full-featured scripting language through this feature, we are still safe, but this is a tricky line to walk.
--Chouser
I figured this would happen once I saw what KDE and gnome were trying to do, namely isolate applications from X completely. Older apps communicate with graphics hardware via X. This meant that graphics hardware could be swapped in and out (and even across the network!). But now both KDE and gnome (with the help of GTK and QT, respecively) have become a complete layer between apps and X. This means it should be possible for KDE and gnome to completely skip X, and go straight to the hardware. The advent of the Linux frame buffer makes this even easier.
There were hints of this already in projects like the now defunct Harmony (FreeQT) in how it handled TrueType fonts.
As others have said, choice is great. It isn't (yet) time for X to die completely, being able to skip the rather large and complex called Xwindows will often be a great boon.
I hope that at some point, all gnome and KDE apps will be run-time (or maybe shared-link time, which amounts to the same thing) switchable between framebuffer and X. Run the app, and if the DISPLAY is local, skip X, otherwise be an X client. ...or something like that, but now I'm just rambling.
--Chouser
Slackware was the first Linux distribution that I ever used. I helped administrate a small- to medium-sized unix network that included a small pile of Slackware Linux machines (along with some Sparcs, some Sun 3/60s, some Alphas, etc.). It was fine. I had no complaints, and it's the distribution that got me hooked on Unix in general and Linux in particular.
Then Debian and RedHat arrived, and I realized how out-of-control things had been under Slackware (and also Solaris and SunOS). The ability to have a tool justify the existance of every file installed on my system was amazing from a sysadmin's viewpoint. And more than that, I could find out what other programs depended on it. This was wonderful, especially for shared libraries.
Because of this experience, I've never really looked back at Slackware. But is it true that Slaskware now has some sort of package management? I must admit I don't really like the convolutions built into the RedHat configuration files -- does Slackware still do this better? Will Slackware warn me if I try to uninstall some part of the system that some other part depends on? Can I tell Slackware that it isn't allowed to install over a particular file (because I've done something special with it?)
These are the reasons I stopped using Slackware. This in no way decreases how grateful I am to Patrick, or how glad I am that there is still a minimalistic, tgz based Linux distribution.
--Chouser
Why should I have to know in which country an organization is based in order to guess their URL? Should we then go down to individual states and provinces? Then instead of the clear, unambiguous slashdot.org, you get the silly slashdot.org.somestate.us. And what if they move? I'm rambling now, but my point is that the internet has the potential to seperate us from awkward physical boundaries, and you are advocating adopting those same boundaries.
Much preferrable would be your first suggestion -- a name heirarchy based on purpose or industry of the registering entity.
--Chouser
- ISPs will jump in and shovel money at AOL faster than individual subscribers would. More instant capital can't hurt.
- More capital means more infrastruture sooner. There are still many areas of the country that don't have cable internet access. First-to-market in these areas is still going to mean a lot of cash.
- Multiple companies depending on their cable infrastructure means a more robust business model -- less suseptible to consumer-level price fluctuations, less vulnerable to Congressional bullying.
I would never recommend depending on the good will of a corporation, but I think in there are enough selfish reasons for AOL to do this that we can reasonable expect it to happen.--Chouser
What makes you so certain the nVidia drivers will be closed? Their current set of drivers are available free for download, even in source form. And they claim that they are working with Precision Insight, DRI, and integrating with XFree86.
Doesn't sound too terribly closed to me.
--Chouser
I agree that Linux seems like somewhat of a poor fit for a PDA. Linux is designed around some hardware assumptions that just aren't true on a PDA (large slow disk + small fast RAM, for example).
On the other hand, PalmOS is closed. Oops.
So what about something like eCos? It's an Open Source Operating System from a well-known company with a decent track record, both technically and license-wise. Does anyone know how well it would work on a PDA? Is there such a project going on already?
--Chouser