The fact that DOS still existed in the "all new" Win95/98 was always ridiculed by Mac/Be/Linux people who claimed it showed that Windows was still nothing more than a shell on top of 20-year-old DOS code... are you, the same people, criticizing Microsoft for removing the oft-ridiculed feature?
I don't see why loadlin, beos, etc need DOS mode anyway. An executable is an executable...it can still kick out windows and start clean. Mac people never had a DOS to work with and we still have BootX which works just fine to load Linux. It's not a big deal.
Assume I am a user on a system that only has emacs and I really love xemacs. Then I install xemacs using
my regular account, "amorsen".
I discover that others need xemacs too, and that they have started using the one I installed. Then I grin
evilly and change the xemacs executable to fork() a little X event watching program before it exec()'s the
actual xemacs. This way I can gather passwords from unsuspecting users.
Software installed by untrusted users should be taken for what it is. In your example it is the other users' fault for using software residing in an unprotected directory, owned by an untrusted user; and it is their accounts which suffer.
When I want to do a "make install" as non-root, I expect it to go somewhere specific to me (like/home/amorsen/bin...) and I should have that option, I think. What kind of fool would run a program in someone else's bin directory?
There are tons of little arguments about why only root should be able to do this, or that, or the other thing. What it results in (for me) is the need to "su" and type my password every two minutes, whenever I want to use the computer to actually do something. This, I think is a BIG flaw. I find myself typing the root password automatically, the way my friend automatically types #include int main(void) {} every time he opens vi. I worry about echelon-style attacks; with me typing the password so much, the pact that I am typing it would be deducible from the keypress rhythm itself. It's not SAFE to have such a black-and-white security model. The entire security model needs to be thought out better. There needs to be a mechanism so that I can request access to the hardware and unless there's a good reason, I should get it.
It may not be UNIX, but UNIX was developed for a time when the only thing that users needed was CPU time. This does not apply to PC's where there actually is a floppy disk/cdrom/interfaces which people need to be able to use.
I propose that we follow Apple's lead in this area and move to Self Extracting
Executables, ELF binaries that you run and will extract the software and install it for you, without
the hassle of remembering arcane flags and what program you're supposed to use.
You need to read up an Apple's OS X packaging model. It's not nearly as stupid.
"extracting the program and installing it for you" is moot because the program and all the things it depends on are self-contained--just download and unpack using your favorite decompression utility, and there you are.
If you care to look at the source, you can look at it--and compiling the source produces the package.
I would not EVER run a system such as you describe.
Seriously, if there were a backdoor in a stable piece of software (one that was well-programmed and never gave anyone trouble,) how soon would it be discovered? Backdoors can be hidden very well (see previous link.)
What really needs to be done away with is the inability to install software as non-root. What *I* want is to be able to do "make install" as NON-root, and have it go into the appropriate directories. That, I think would be a reasonable level of security.
5. Teach them / let them learn how to use Gtk+ or Xlib. X-programming[is] fun(after the fear goes away...), but I wish somehow I could get taught to use Gtk+.
Similarly, if you want to learn how to use Perl, try typing "man perl."
Granted, there are occasions where you want to buy yourself a book. But the book to buy is NOT going to be titled "Teach yourself (well documented system) in (N) (days|steps|lessons)."
So that people could switch from Flash to their tools.
Consider this, can Adobe's solution export Flash graphics?
Um, the whole RIAA/Napster/Courtney Love controversy wasn't around when Our Dumb Century was pulished...
I don't see why loadlin, beos, etc need DOS mode anyway. An executable is an executable...it can still kick out windows and start clean. Mac people never had a DOS to work with and we still have BootX which works just fine to load Linux. It's not a big deal.
Software installed by untrusted users should be taken for what it is. In your example it is the other users' fault for using software residing in an unprotected directory, owned by an untrusted user; and it is their accounts which suffer.
When I want to do a "make install" as non-root, I expect it to go somewhere specific to me (like /home/amorsen/bin...) and I should have that option, I think. What kind of fool would run a program in someone else's bin directory?
There are tons of little arguments about why only root should be able to do this, or that, or the other thing. What it results in (for me) is the need to "su" and type my password every two minutes, whenever I want to use the computer to actually do something. This, I think is a BIG flaw. I find myself typing the root password automatically, the way my friend automatically types #include int main(void) {} every time he opens vi. I worry about echelon-style attacks; with me typing the password so much, the pact that I am typing it would be deducible from the keypress rhythm itself. It's not SAFE to have such a black-and-white security model. The entire security model needs to be thought out better. There needs to be a mechanism so that I can request access to the hardware and unless there's a good reason, I should get it.
It may not be UNIX, but UNIX was developed for a time when the only thing that users needed was CPU time. This does not apply to PC's where there actually is a floppy disk/cdrom/interfaces which people need to be able to use.
You need to read up an Apple's OS X packaging model. It's not nearly as stupid. "extracting the program and installing it for you" is moot because the program and all the things it depends on are self-contained--just download and unpack using your favorite decompression utility, and there you are.
If you care to look at the source, you can look at it--and compiling the source produces the package.
I would not EVER run a system such as you describe.
"But open source guarantees security!" someone says. "A thousand eyes looking at the code..."
um, no. Uberhacker Ken Thompson says why.
Seriously, if there were a backdoor in a stable piece of software (one that was well-programmed and never gave anyone trouble,) how soon would it be discovered? Backdoors can be hidden very well (see previous link.)
What really needs to be done away with is the inability to install software as non-root. What *I* want is to be able to do "make install" as NON-root, and have it go into the appropriate directories. That, I think would be a reasonable level of security.
Personally. I tend to have a browser open all the time (usually reading documentation with it.) Good thing I don't have a working Java in my Netscape.
No really, I am.
Fine. Don't believe me. I didn't like you anyway.
Actually you cound win this with Fisheye Quake and get better visibility.
no, you only need ot be at a college, where they throw out tons of 19 inch workstation monitors every day.
sqrt(720^2+480^2)/13 inches ~= 66dpi. Then why aren't we printing out books at 72dpi? think BEFORE you put your foot in your mouth.
Try this.
After you finish that you can use the reference manual..
Similarly, if you want to learn how to use Perl, try typing "man perl."
Granted, there are occasions where you want to buy yourself a book. But the book to buy is NOT going to be titled "Teach yourself (well documented system) in (N) (days|steps|lessons)."