With respect to monoculture, there are at least four DNS server implementations out there - BIND 4/8, BIND 9, djbdns and Microsoft. If you're afraid of the BIND monoculture and you're running BIND 8, you do have alternatives. Personally I run BIND 9 on my alpha, which takes care of the monoculture issue for me.:')
If UNIX/LINUX treats everything like a file, why not TCP/IP ports, too? That way, you could assign a port to a group/user who could access that port without being root!!!
Ahh, yes. Somebody finally noticed. Unfortunately TCP/IP was not added to UNIX until BSD in the 80's. So we have BSD Sockets and the "Everything is a File" mantra no longer holds.
I believe that Plan9, now known as Inferno, works this way. It was developed in the late 80's/early 90's by the original UNIX people at Bell Labs. Lucent (Bell Labs) has released Plan9 source under their own license, source and binaries can be downloaded here.
KDE2 actually does this, if it can't determine the filetype from the name it runs file(1) on it to determine what the proper MIME type should be. I believe that this information should be stored with the file meta-data, it would seem to be too much of a performance penalty to scan the file every time it is accessed. The MIME type could be determined when the file is created and whenever the file is closed after writing.
I'm hoping the annoying "won't let go of a previous URL no matter what you type in" bug is gone, and I'm hoping there's a bit more javascript support (the only two complaints I've had with it since the the later beta versions and on). I notice it still doesn't seem to support "javascript:" URLs
I believe that the URL bug(s) were/are caused by Klippy the super-duper clipboard manager. It appears to poll the X cliboard every 1-2 seconds for changes, this seems to give Konqueror and Mozilla problems now and again. This wasn't listed in the fixes in their press release but I hope they fixed it, I use Klippy heavilly at work when filing security incidents.
SCO always turns up in the most unusual places, it seems to give the warm fuzzies to large embedded systems people. I've seen it in telephone systems, satellite equipment, automobile diagnostics, etc.
Think of how much the school systems could save, if each district didn't have to pay millions for crappy on-off, outdated applications from houghton-mifflin or macmillan or whatever...
On a side note, isn't Mandrake funded by Macmillan? They are in the perfect position to sell software to schools. With the recent release of OpenOffice they could profide a complete office automation system for schools. This would also be a good way for students to learn some real computer skills instead of how bad systems behave irrationally and the magic three fingered salute.
Hey, wait a minute, how does Carnivore get its logs back to the FBI?
Is the FBI going to have removable media in this thing and have the
logs sent by snail-mail? Otherwise how the heck is this thing going
to transmit stuff back when its installed at a busy site with a saturated
outgoing connection? Would the ISP be able to do traffic analysis on the
transmitted traffic to determine what kind of data the thing is logging?
/usr is filled with the system binaries and libraries, not seperate, individual applications. Any large user application should be installed in/opt and any additional software installed after the system itself is installed should go into/usr/local. Having seperate directories for cat, awk, even perl with symlinks would not be efficient or usefull to a user since this is software that the user won't be installing/removing by themselves. I know this is a poor explanation but I am running out the door for lunch right now.
There is no need for multiple, mutually incompatable systems for doing the same thing. Diversity is one thing but code reuse and compatability is more importent here. The tired old example of "What if everybody used a different, incompatable but similar network protocol stack" applies here.
Oh, I forgot, also Debian packages generally have much nicer pre and post-install scripts. You can do that very easily with RPM as well but in my experience that breaks many RPM frontends that don't watch STDIN/STDOUT for RPM's requiring input and just break. Packages really should ask you for the defaults you want your system to have if it can't easilly pick sane defaults by itself.
That's the big problem with RPM, it can do almost everything that Deb can but there isn't the ironfisted standards that Debian has for its packages. Therefore dependancies break when you try to install packages from one RPM based distro to annother RPM based distro. For example one distro might have "Provides: MTA" and annother could have "Provides: email-server" for the same package, or one might install in/opt on one distro and/usr/local on annother.
Some of these problems could be solved by having alot more default groups as well as a more capabilities based security model, instead of the "root uber alles" security model. Different subsystems should have different group ownerships and you should be able to pick who has control of what subsystems at install time. Also a sane sudo config at install time would be a plus. That would allow Joe User to change resolv.conf and Jane User the hosts file but not destroy the sendmail settings or install a trojan accidently. It think we could use finer grained access controls than root and user.
I like the idea of installing more stuff in the individual's home directory, but that won't work right if you do have multiple people using a household computer.
I do see some problem with having per-user system settings, in that it could be a big pain for a neophyte to troubleshoot. It would seem to add unnecessary complexity.
You are thinking of GNU Stow which does exactally this. While I wouldn't recommend this type of file layout for/usr,/usr/local and/opt are annother matter entirely and I would recommend Stow type packaging there.
There's one main reason that GUI conf tools are usually eaiser for newbies, and that's Context. If I open/etc/hosts in VI, or PICO, there is no contextual information letting me know what goes where, what options are valid, etc. With a GUI I have textboxes, tooltip help, labels, etc. that let me figure out what value needs to go where. If you don't know how to edit a particular file you are going to have to flip back and forth with the man(1) page and it will probably be a long and pointless process, especially if it is something you aren't going to have to do again like resolv.conf.
A good example of a conf file that does not need a GUI editer, though, is squid.conf. It is very long and has the entire text of the configuration guide, with examples, as comments in the live conf file. All the help and context is right there, I wish more file maintainers would take a look at their lead.
SMIT for AIX has this functionality. If it runs a command you can see the exact command line, with all the options in place. If it runs a script you can see the contents of the script. SMIT does not appear to rely on any internal, hard coded programming, for every configuration activity it runs an external command or script.
Since I have only done a little AIX admin work I could be somewhat wrong, if so please correct me.
While I have nothing to hide in my emails, I guess its just starting to piss me off that all the governments of the world are starting to take their turns reading my email just in case I might be a terrorist threat. Seriously now, how many terrorist organisations would be dumb enough to not encrypt their emails that they send to each other, its ludicrous. I for one am going to start encrypting everything just to piss of the government...
Also it is worth noting that most legitimate targets for SIGINT have dried up over the years. Crypto like DES, RSA, Blowfish, etc. has been around for many years and is for all practical purposes unbreakable. Except for the occasional slip-up, and traffic analysis, there is no data to be gleaned from legitimite targets, they are mostly smart enough to use an unbreakable crypto scheme. I believe that legitimate for for SIGINT are only Military or Diplomatic targets. The only things that use weak or no crypto are private and commercial communications. Therefore it seems that much of the data gleaned by SIGINT is going to be non-Government targets, that they shouldn't be targeting.
Personally I think that most of the SIGINT force should have been buried when strong crypto made is so much less effective. It only exists now as a possible threat to liberty if it ever falls into the wrong hands. Like the START and SALT nuclear weapons treaties, this weapon too should be disarmed and disbanded.
If annother big war comes then we may need to revive the old knowlege but I don't want to see our SIGINT services turned into the agents of some Big Brother/Though Police organization--only used to keep Commerce high and the people in control. The road to Hell is paved with good intentions they say, and there need be no "Grand Conspiritor", only people doing what they believe is right and what they believe is in their best interest.
I'm going to make the argument that the POSIX CLI is the closest thing we have to language parsing right now. Unfortunately/usr/bin is chock full of unusual programs with non-intuitive names and each one has to be learned seperately. The GNU project has done wonders with the standard POSIX utilities, having '-h --help' and long options '--this-option-here=foo'.
Where we need to go from here is a standard, well named and optioned, command set that is very easy to figure out, given a little training and a few rules. For example if a utility can have file input it should take the argument '-f or --file' and that should be standard. I have been using Linux and other Unices for several years and still have to look at the man pages for common commands. Annother example is the very useful utility awk(1), there is no way I would have found it by myself and no way I would have learned its syntax by myself, the find(1) utility is similar in that I still have to look up the man page for exact syntax when I use it.
I know that I am rambling on but I really think that CLI interfaces with output-mainly windowing displays should be our future, but not if the full power of the environment isn't accessable but to gurus. My mom should be able to type "print foo.txt --duplex --pretty-print" instead of having to remember "enscript -2rG --pretty-print=xyz -DDuplex:true foo.txt" or "list foo.txt | search for 'sometext' | print --with-fancy-header --page-numbers --to=Ywindow"
I disagree with this, making it the developers responsibility to write bounds checking code every time they deal with input is why we are in this mess today. Not a week goes by without annother buffer overflow sob story on Bugtraq. Asking software developers never to make any mistakes, ever, is not a realistic solution and assigning blame isn't going to make the problem go away.
There are a few possible solutions, none of them really easy.
Change the libraries to always do bounds checking on all functions. This would break most current software and still wouldn't solve problems inherent in language. It would still be possible to write insecure code if you decided to shoot yourself in the foot, or the libraries were used in new and unusual ways.
Change the language to one that is type safe. This probably won't realistically happen any time soon but Java is making some inroads in popularity. Other languages, especially the LISPy ones, will probably never be popular, but who knows? Still doesn't fix old software, or programmers who refuse to learn.
Change the OS with something like StackGuard. Will break much existing software and OS implementations, and there are still many ways around it for creative programmers. This is just a patch that doesn't solve the inherent problems of writing insecure code.
Change the hardware platform. Certain platforms make it much easier to create safe code, and protect you from some nastiness. This might work, and for legacy, current and future software but isn't an area I am much familiar with so I don't know all the implications. It should be pretty hard to get around hardware restrictions but backwards compatibility features might provide a way to run old, insecure, code in old insecure ways.
Buffer overflows and other common security problems have been with us for over thirty years and still aren't in the "solved problems" bin. This is inexcusable. If people are going to rely on computers in their daily lives, the computer have to be reliable and having the possibility of security comprimise using 30 year old techniques does not a reliable computer make.
While I agree that LyX is a great tool, writing good LaTeX requires that you approach your writing from a very different angle. Moving from Word to WordPerfect, for example, could probably be accomplished with very little retraining for a majority of users. Moving from a wordprocessor (read, glorified typewriter clone) to a document processing system like LaTeX is a bit more difficult. Teaching users that they shouldn't worry about formatting but only about tagging the content appropriately can be a hurdle. One has to create several documents using TeX before they really understand what the software can do for you.
Personally I am a recent LaTeX convert, and am very happy how my productivity has increased. Time spent fiddling with section numbering, cross references, margins, pagebreaks, tables (God help anyone who creates tables in Word), verbatim examples, fonts, page numbering, etc. is now spent actually working because the software does all those things for you (effectively and efficiently) and you get things like beautiful output with Table of Contents, Index pages and nice headers/footers (with included section/chapter name etc.) for free.
You also get excellent printed output, PostScript (which can be easily converted into PDF), ASCII Text and HTML that doesn't suck. I can spend minutes creating something, or hours of frustration trying to get things to look right--I know what choice I will be making.
The real problem is that Microsoft will use the same tactics it used with IBM, If you are an OEM, and you DON'T bundle a microsoft productivity suite with your systems, microsoft will either refuse to sell, or charge an extremely high price for the windows system software you need for your business to survive.
This probably won't happen as the fallout from the anti-trust trial should preclude the continuation of this predatory and illegal practice.
This is NOT Corel's death-knell, they are merely selling off some of their clip-art libraries. It's not like clip-art is their core business. They even get to retain permanent license to the material, so that they can still sell clip-art with their graphics programs.
This seems like a win/win scenerio, and annother case of Slashdot overemotional reporting.
What I was trying to say was that some components are winelib native executables while some are WINE emulated Win32.exe's. AFAIK the entire package is _not_ run under WINE emulation, only the components that they had trouble porting directly to winelib. I hope that in the future a service pack will replace the Win32.exe's and shell scripts with native executables.
Now that is provably false. The confusion is from the fact that they are using winelib from the WINE project as the compatability layer to port their Win32 version directly over to native Linux. Most people assume WINE means "emulation" (I know it is not an emulator, but humor me). There is even more confusion because not all the components built as native Linux binaries so some things are Linux/winelib and others are Win32/WINE, also some components appear to have the same naming conventions as Win32, *.exe files and such.
Corel is definately NOT giving up on Linux, in fact they are betting their entire future on it.
Everything besides the speech recongnition sounds right on the money. Probably more realistic would be a pen-and-paper like interface. Point and draw, select from menus and checkboxes, hopefully without a "windowing" interface (everything fullscreen) with forward and back buttons.
I used to see these in Europe, bubblegum in the Bazooka formfactor with pr0n stickers wrapped up inside. I stuck a whole bunch in the inside of my hat--to make it "softer".
Slashdot Mirror
Don't forget Novell DHCP/DNS, it comes with NetWare 5. There are more esoteric DNS servers listed here.
Ahh, yes. Somebody finally noticed. Unfortunately TCP/IP was not added to UNIX until BSD in the 80's. So we have BSD Sockets and the "Everything is a File" mantra no longer holds.
I believe that Plan9, now known as Inferno, works this way. It was developed in the late 80's/early 90's by the original UNIX people at Bell Labs. Lucent (Bell Labs) has released Plan9 source under their own license, source and binaries can be downloaded here.
Have Fun!
KDE2 actually does this, if it can't determine the filetype from the name it runs file(1) on it to determine what the proper MIME type should be. I believe that this information should be stored with the file meta-data, it would seem to be too much of a performance penalty to scan the file every time it is accessed. The MIME type could be determined when the file is created and whenever the file is closed after writing.
Just my $0.02
I believe that the URL bug(s) were/are caused by Klippy the super-duper clipboard manager. It appears to poll the X cliboard every 1-2 seconds for changes, this seems to give Konqueror and Mozilla problems now and again. This wasn't listed in the fixes in their press release but I hope they fixed it, I use Klippy heavilly at work when filing security incidents.
SCO always turns up in the most unusual places, it seems to give the warm fuzzies to large embedded systems people. I've seen it in telephone systems, satellite equipment, automobile diagnostics, etc.
On a side note, isn't Mandrake funded by Macmillan? They are in the perfect position to sell software to schools. With the recent release of OpenOffice they could profide a complete office automation system for schools. This would also be a good way for students to learn some real computer skills instead of how bad systems behave irrationally and the magic three fingered salute.
Hey, wait a minute, how does Carnivore get its logs back to the FBI? Is the FBI going to have removable media in this thing and have the logs sent by snail-mail? Otherwise how the heck is this thing going to transmit stuff back when its installed at a busy site with a saturated outgoing connection? Would the ISP be able to do traffic analysis on the transmitted traffic to determine what kind of data the thing is logging?
So many questions, so few answers.
/usr is filled with the system binaries and libraries, not seperate, individual applications. Any large user application should be installed in /opt and any additional software installed after the system itself is installed should go into /usr/local. Having seperate directories for cat, awk, even perl with symlinks would not be efficient or usefull to a user since this is software that the user won't be installing/removing by themselves. I know this is a poor explanation but I am running out the door for lunch right now.
There is no need for multiple, mutually incompatable systems for doing the same thing. Diversity is one thing but code reuse and compatability is more importent here. The tired old example of "What if everybody used a different, incompatable but similar network protocol stack" applies here.
Oh, I forgot, also Debian packages generally have much nicer pre and post-install scripts. You can do that very easily with RPM as well but in my experience that breaks many RPM frontends that don't watch STDIN/STDOUT for RPM's requiring input and just break. Packages really should ask you for the defaults you want your system to have if it can't easilly pick sane defaults by itself.
That's the big problem with RPM, it can do almost everything that Deb can but there isn't the ironfisted standards that Debian has for its packages. Therefore dependancies break when you try to install packages from one RPM based distro to annother RPM based distro. For example one distro might have "Provides: MTA" and annother could have "Provides: email-server" for the same package, or one might install in /opt on one distro and /usr/local on annother.
Some of these problems could be solved by having alot more default groups as well as a more capabilities based security model, instead of the "root uber alles" security model. Different subsystems should have different group ownerships and you should be able to pick who has control of what subsystems at install time. Also a sane sudo config at install time would be a plus. That would allow Joe User to change resolv.conf and Jane User the hosts file but not destroy the sendmail settings or install a trojan accidently. It think we could use finer grained access controls than root and user.
I like the idea of installing more stuff in the individual's home directory, but that won't work right if you do have multiple people using a household computer.
I do see some problem with having per-user system settings, in that it could be a big pain for a neophyte to troubleshoot. It would seem to add unnecessary complexity.
You are thinking of GNU Stow which does exactally this. While I wouldn't recommend this type of file layout for /usr, /usr/local and /opt are annother matter entirely and I would recommend Stow type packaging there.
There's one main reason that GUI conf tools are usually eaiser for newbies, and that's Context. If I open /etc/hosts in VI, or PICO, there is no contextual information letting me know what goes where, what options are valid, etc. With a GUI I have textboxes, tooltip help, labels, etc. that let me figure out what value needs to go where. If you don't know how to edit a particular file you are going to have to flip back and forth with the man(1) page and it will probably be a long and pointless process, especially if it is something you aren't going to have to do again like resolv.conf.
A good example of a conf file that does not need a GUI editer, though, is squid.conf. It is very long and has the entire text of the configuration guide, with examples, as comments in the live conf file. All the help and context is right there, I wish more file maintainers would take a look at their lead.
SMIT for AIX has this functionality. If it runs a command you can see the exact command line, with all the options in place. If it runs a script you can see the contents of the script. SMIT does not appear to rely on any internal, hard coded programming, for every configuration activity it runs an external command or script.
Since I have only done a little AIX admin work I could be somewhat wrong, if so please correct me.
Also it is worth noting that most legitimate targets for SIGINT have dried up over the years. Crypto like DES, RSA, Blowfish, etc. has been around for many years and is for all practical purposes unbreakable. Except for the occasional slip-up, and traffic analysis, there is no data to be gleaned from legitimite targets, they are mostly smart enough to use an unbreakable crypto scheme. I believe that legitimate for for SIGINT are only Military or Diplomatic targets. The only things that use weak or no crypto are private and commercial communications. Therefore it seems that much of the data gleaned by SIGINT is going to be non-Government targets, that they shouldn't be targeting.
Personally I think that most of the SIGINT force should have been buried when strong crypto made is so much less effective. It only exists now as a possible threat to liberty if it ever falls into the wrong hands. Like the START and SALT nuclear weapons treaties, this weapon too should be disarmed and disbanded.
If annother big war comes then we may need to revive the old knowlege but I don't want to see our SIGINT services turned into the agents of some Big Brother/Though Police organization--only used to keep Commerce high and the people in control. The road to Hell is paved with good intentions they say, and there need be no "Grand Conspiritor", only people doing what they believe is right and what they believe is in their best interest.
Annother rant filed.
I'm going to make the argument that the POSIX CLI is the closest thing we have to language parsing right now. Unfortunately /usr/bin is chock full of unusual programs with non-intuitive names and each one has to be learned seperately. The GNU project has done wonders with the standard POSIX utilities, having '-h --help' and long options '--this-option-here=foo'.
Where we need to go from here is a standard, well named and optioned, command set that is very easy to figure out, given a little training and a few rules. For example if a utility can have file input it should take the argument '-f or --file' and that should be standard. I have been using Linux and other Unices for several years and still have to look at the man pages for common commands. Annother example is the very useful utility awk(1), there is no way I would have found it by myself and no way I would have learned its syntax by myself, the find(1) utility is similar in that I still have to look up the man page for exact syntax when I use it.
I know that I am rambling on but I really think that CLI interfaces with output-mainly windowing displays should be our future, but not if the full power of the environment isn't accessable but to gurus. My mom should be able to type "print foo.txt --duplex --pretty-print" instead of having to remember "enscript -2rG --pretty-print=xyz -DDuplex:true foo.txt" or "list foo.txt | search for 'sometext' | print --with-fancy-header --page-numbers --to=Ywindow"
I disagree with this, making it the developers responsibility to write bounds checking code every time they deal with input is why we are in this mess today. Not a week goes by without annother buffer overflow sob story on Bugtraq. Asking software developers never to make any mistakes, ever, is not a realistic solution and assigning blame isn't going to make the problem go away.
There are a few possible solutions, none of them really easy.
Buffer overflows and other common security problems have been with us for over thirty years and still aren't in the "solved problems" bin. This is inexcusable. If people are going to rely on computers in their daily lives, the computer have to be reliable and having the possibility of security comprimise using 30 year old techniques does not a reliable computer make.
While I agree that LyX is a great tool, writing good LaTeX requires that you approach your writing from a very different angle. Moving from Word to WordPerfect, for example, could probably be accomplished with very little retraining for a majority of users. Moving from a wordprocessor (read, glorified typewriter clone) to a document processing system like LaTeX is a bit more difficult. Teaching users that they shouldn't worry about formatting but only about tagging the content appropriately can be a hurdle. One has to create several documents using TeX before they really understand what the software can do for you.
Personally I am a recent LaTeX convert, and am very happy how my productivity has increased. Time spent fiddling with section numbering, cross references, margins, pagebreaks, tables (God help anyone who creates tables in Word), verbatim examples, fonts, page numbering, etc. is now spent actually working because the software does all those things for you (effectively and efficiently) and you get things like beautiful output with Table of Contents, Index pages and nice headers/footers (with included section/chapter name etc.) for free.
You also get excellent printed output, PostScript (which can be easily converted into PDF), ASCII Text and HTML that doesn't suck. I can spend minutes creating something, or hours of frustration trying to get things to look right--I know what choice I will be making.
This probably won't happen as the fallout from the anti-trust trial should preclude the continuation of this predatory and illegal practice.
This is NOT Corel's death-knell, they are merely selling off some of their clip-art libraries. It's not like clip-art is their core business. They even get to retain permanent license to the material, so that they can still sell clip-art with their graphics programs.
This seems like a win/win scenerio, and annother case of Slashdot overemotional reporting.
What I was trying to say was that some components are winelib native executables while some are WINE emulated Win32 .exe's. AFAIK the entire package is _not_ run under WINE emulation, only the components that they had trouble porting directly to winelib. I hope that in the future a service pack will replace the Win32 .exe's and shell scripts with native executables.
Now that is provably false. The confusion is from the fact that they are using winelib from the WINE project as the compatability layer to port their Win32 version directly over to native Linux. Most people assume WINE means "emulation" (I know it is not an emulator, but humor me). There is even more confusion because not all the components built as native Linux binaries so some things are Linux/winelib and others are Win32/WINE, also some components appear to have the same naming conventions as Win32, *.exe files and such.
Corel is definately NOT giving up on Linux, in fact they are betting their entire future on it.
Everything besides the speech recongnition sounds right on the money. Probably more realistic would be a pen-and-paper like interface. Point and draw, select from menus and checkboxes, hopefully without a "windowing" interface (everything fullscreen) with forward and back buttons.
I used to see these in Europe, bubblegum in the Bazooka formfactor with pr0n stickers wrapped up inside. I stuck a whole bunch in the inside of my hat--to make it "softer".