There are no anonymous functions above (Python doesn't really support them, which was a part of what I said in the above post). I have no idea if Javascript supports dynamic functions (if so, it's got plenty of company); I was simply responding to the assertion that Python doesn't.
Plenty of languages do support dynamic function creation. Scheme, smalltalk, and lisp are good non-python examples.
Yeah, but I shouldn't have to use a separate tool. If it's a good idea to run such checks -- and, IMHO, it always is -- it should be built in to the standard language.
Think about it this way: There is no compile phase for your program. If you want to run lint, you can. If not, you don't have to. But it's not an "additional step" relative to a statically typed language.
And there are good reasons not to lint, many of them the same reasons that you would pick a dynamically typed language in the first place. I lint at the least before any code is checked in (our repository enforces that--you can't check in any code that isn't pylint-clean), but for rapid prototyping and testing it's not necessarily worth it.
(Pylint can even enforce policy, like making sure naming conventions, formatting conventions, etc are followed)
In a statically typed language I agree with keepin g the warning levels cranked up at all times. Since you can only test your code at points where static analysis is possible, you may as well not do it half-assed.
And this shows you don't know squat about Lisp. Lisp is not merely a functional language
I never said it was. I said that Python wasn't.
Both of them are multi-paradigm languages, but Python's support for functional programming is weaker than Lisp's. Still stronger than, say, Java's, but that's not saying much.
(and Python is even worse at pattern-driven programming)
you've confused dynamic typing with weak typing. Python is weakly typed and java is strongly typed. Both languages have strong dynamic typing.
Wrong. Strong and static are orthogonal. Static vs. dynamic refers to whether the language does type checking at compile time or at run time. Weak vs. strong refers to whether the type system can be circumvented or whether operations are type-safe.
Both properties are continuums, not booleans. It's reasonable to say:
C's typing is weak and static. C++'s typing is weak and static Java's is strong and static ML's is strong and static Tcl's is weak and dynamic Python's is strong and dynamic.
BUT:
C++ has stronger typing than C, and it has rtti and other mechanisms to do dynamic type checking at runtime. But it's basically weakly typed in the realm of all languages, and it's basically statically typed.
Java is more weakly typed than ML, but it's still basically strongly typed. It's more dynamically typed than Ada, but it's still basically statically typed.
I love Python. But I've shot myself in the foot enough times, with dynamic typing, to realize that strong typing is better for many things...but you have it wrong. First, Python _is_ strongly typed. It is not statically typed. The two concepts are orthogonal (e.g. C is statically typed but not strongly typed).
Second, for many problem domains--especially the development of large web applications--dynamic typing has huge advantages over static typing.
And third, if you're dead-set on static typing, consider a language with type inference and _very_ strong typing (e.g. ML, Haskell, or Dylan -- ocaml is a very nice ML implementation)
IOW, typing is a huge factor. But it is not a better/worse thing except relative to certain problem domains.
Name me ONE TASK that Python (or Java) can do that the other can't. Both are turing complete, and you could implement a Python interpreter in Java or vice-versa. If "it's possible somehow" is your measure, then there's no reason to choose Java over assembly.
In the end, it comes down to this: what is your personal coding style? What sort of syntax are you most comfortable with?
Syntax is largely irrelevant, people learn it quickly. Much more important are things like:
* Do I have strong typing or not? (Python, Java, ML, Ada vs C, C++, Tcl) * Do I have dynamic typing or static (Python, Lisp, Tcl vs. Ada, C, Java, ML) * How good is the language I'm using at modelling the problem I'm trying to solve? * How good is the language at expressing things clearly and concisely * How easy is it to reuse code/read code written by others/maintain large systems
Things like functional programming, pattern matching (NOT regex matching of strings, but real ML-style pattern matching), object orientation, metaprogramming, dynamic code generation, hygienic macros, the type model, etc all have REAL affects on how easily and elegantly you can solve a problem.
Less sexy but equally useful are details like "are flexible mappings a language feature or a library add-on", which seems trivial but makes a huge difference in practice.
Some of those features are very important when doing certain things and nearly useless when doing other things.
But programming languages definitely CAN be "better" than each other with respect to certain problem domains, and Python and Java differ in one of the most fundamental ways there is (more fundamental than e.g language-level support for object oriented programming, in my opinion) in that Java is statically typed and Python is dynamically typed.
aspects. Aspects are stupid. They make sense in a language like Java that has no metaprogramming capabilities. They are absurd in other languages like Python or Lisp.
Aspects are not macros and macros cannot do everythin that aspects can.
Macros are not metaprogramming and macros cannot do everything that metaprogramming can. Go read up on metaprogramming.
(Python doesn't even _have_ macros, but it certainly has metaprogramming)
I know that Python has some very nice features (I read the tutorial) but it's hardly the sort of paradigm shift
static typing vs. dynamic typing is one of the MOST fundamental differences between programming languages. It has a tremendous effect on how you approach software design and how you engineer large systems.
Python is hardly the first dynamic language out there, but Paul knows that quite well.
To me, thats a very strange statement. The standard library of Java is, IMHO, one of the strongest around.
Ugh. Java as a language is rather nice (for a statically typed, non type-inferred language). The standard library is pretty unwieldy and inconsistent, though; I find myself fighting against the library more often than working with it.
How do you create anonymous functions and pass them as variables in Python? You can't, only "lambda *expressions*" which is a strange and arbitrary distinction. In Lisp, creating functions on the fly is the norm.
In theory, Python is different from Lisp in a lot of ways. It's really not a functional language, though it does allow more flexibility in that direction than many basically OO languages.
In practice, I often find myself using a lot of dynamic functional techniques when I'm programming in Python.
You're correct about anonymous functions, but it's trivial to create named functions on the fly in Python. They can't be anonymous, but you can reuse the name immediately (either after the function isn't needed or after storing it in a dictionary or something). (Underscores addes since slashdot mangles whitespace)
Does anyone really do anything other than just blindly hit "yes" when presented with a new host identification string?
If I know the machine just got wiped out or replaced, I'll hit yes. Otherwise, I'll investigate via outside channels. I've uncovered more than one DNS problem by investigating those messages.
Note that Linus did a 180 on "Linux Threads" versus "POSIX Threads" because Linux vendors wanted portability
Actually, he quite rightly didn't want to implement POSIX threads in the kernel originally, but went for a much more flexible Plan-9 style clone() call originally.
He never "did a 180" on this, either. He originally wanted a userspace implementation on top of Posix threads, which is what Xavier Leroy's LinuxThreads package was. Then Ingo cam along and made another implementation in userspace called NPTL. During the process of designing it he discovered that a few features at the kernel level (most notably futexes and the CLONE_DETACHED option) could help tremendously. futexes are useful for many things outside of Posix threads (Linus insisted on making a generic mutual exclusion mechanism rather than one that's pthread-specific), and CLONE_DETACHED is no different from similar flags that had been added before.
In short, Linus merely switched his endorsement from one implementation of pthreads at the userspace level to another. Had Xavier Leroy come up with a fast kernel mutex implementation, Linus probably would have accepted that as well. The original idea, though--that of using a much more general (and flexible, and easier to maintain) clone() call rather than implementing Posix threads at the kernel level--has not changed at all. In fact, at least some Java implementations use the native Linux threads without the POSIX wrappers, as do certain web servers.
This is different from the GNU/Linux argument, which is about complete distributions.
Saying the OS is Linux-like is completely reasonable given that most CS people consider OS to mean roughly "The minimal system that interfaces to the hardware". The only major OS component of a standard Linux distribution that isn't part of Linux is graphics drives provided by the X server; arguably, init and the shell could be included, but the amount of GNU code is certainly FAR smaller than the amount of Linux or X11 code in the OS itself, and certainly a lot of people use tcsh, zsh, or another shell.
There's a case for calling the complete distribution GNU/Linux, but not much of one at the OS level.
And there isn't much of a case for saying that UNIX is a Linux-like system as a whole (yet).
See, e.g., the Free Online Dictionary of Computing:
(OS) The low-level software which handles the interface to peripheral hardware, schedules tasks, allocates storage, and presents a default interface to the user when no application program is running.
Or the Jargon File: operating system: n. [techspeak] (Often abbreviated 'OS') The foundation software of a machine; that which schedules tasks, allocates storage, and presents a default interface to the user between applications.
I don't remember there I read this, but someone once explained that while *BSD isn't trademark UNIX, it definitely is genetic Unix. Linux, on the other hand, isn't Unix at all, but merely a workalike
To my mind, Unix is 3 things; an OS implentation, a trademark, and an OS family. BSD is the third and first, Solaris is all 3. Linux is the latter. I can't see any good reason that Linux would want the 1st or 2nd. POSIX certification seems much more useful, since (at least historically) being trademark Unix doesn't make many strong guarantees about your behavior--Xenix still had major differences from "real Unix" even after SCO had it and was legally calling it Unix.
However, if it was automated, either that the distro set such things up for every user, or there would be a good tool
What counts as good?
e.g. if there was a JailService script where you could say:
sudo JailService mozilla joe-mozilla sudo JailService pine joe-pine
and it set up the user accounts for that, copied over configs, added/home/joe/bin/mozilla that automagically ran mozilla as joe (similar for pine), and updated the Gnome configuration to use those services, would that be sufficient? (along with little things like symlinking ~/incoming/mozilla to ~joe-mozilla/incoming so that you could save files)
would that be enough to get you to use it?
This is really something that distros should have as an option out of the box, at least for the browser and mail reader.
given everything I've heard about production code "going gold" while still rough polished brass, that's going to be a lot of third party SUID security holes. I'd say that the difference in protection quality amounts only to guarding against local user ignorance/stupidity...
I disagree, strongly. Limiting the window of time when root code is running and its exposure to inputs from malicious sources can be extremely important in general, and in many cases may be "good enough". Imagine the common case of a game that requires Admin privs to implement some copy protection scheme, where the game is a multiplayer networked game.
If the game is run as Administrator, then any remote exploit in the game elevates to Admin privs on the local machine.
If the game uses a small suid helper to do some copy protection stuff at startup, the suid helper can exit before any network code is started. Remote exploits are limited to the privs of the user.
The suid program may even be buggy as heck itself, but if it never takes input that might be from a malicious source then a fairly class of exploits are protected against.
Even in UNIX, SUID files are one of the things you need to watch closely.
No doubt. But if the alternatives are running a large untrusted game as Admin or running a smaller untrusted helper program as Admin, at least the latter reduces the sheer size of code that the untrusted party could have gaping security holes in (as well as the window of time for an exploit).
Obviously if the untrusted party is malicious (rather than just a source of potentially unaudited, insecure code) then either option is going to give them Admin power full stop.
There's no reason to run every program under the same account; in particular, programs that deal with potentially malicious data a lot can benefit greatly from running as their own user.
On my machine at home, I run my email client, web browser, newsreader as seperate users (if I'm "joe", they'd run as "joe-mail", "joe-news", and "joe-www"). The mail and news are almost completely isolated in chroot jails; I have links to their data in my home dir (and I have full read/write access to them, but not vice-versa). So viruses in email could clobber my mail, but couldn't touch anything else.
The browser account is similar, but it has X11 access which has a lot more potential for havoc. I used to run the browser on vncserver, with a vncclient for that. That proved to be a bit too much of a pain for me.
Once the setup was done, the whole thing is transparent to the user (clicking the launch icons does the appropriate magic behind the scenes to run things as the other users).
You can even set up per-user firewall rules that (for instance) only allow the joe-mail account to connect to selected IMAP/POP/SMTP servers.
But I guess I'm curious as to why nearly all OS focus is on UNIX or a derivative? From Linus's knock off, to Mac moving to a UNIX core to even the pretty original BeOS. Why are we reinventing the wheel and not coming up with something completely new?
This is not a troll, I am just looking for the various opinions. Is UNIX the basis for everything non-Microsoft because it's the pinnacle of perfection? Or, like movie plots, did 1 person invent a good thing and everyone else just replicates it with their own flare?
Unix is 3 things, an OS implementation (AT&T Unix code), an OS family (Unix, BSD, Linux, etc), and a philosophy.
The implementation obviously changes with every member of the family, so I assume your question is something like "are we sure the Unix philosophy is good, and why do we keep reimplementing that instead of improving it?"
The philosophy comes down to a couple of ideas which are pretty well articulated these days (everything is a file, do one thing well, etc), but they weren't written down or even well-considered at the time the original implementation was written. They weren't even strictly adhered to (ioctls, anyone?), but even the original managed to stick to them most of the time.
That philosophy can be refined and extended, as was done with Plan 9.
Indeed, some MAJOR improvements have been introduced under the radar in modern Unices. Linux 2.6, for instance, has per-process namespaces, which is an incredible step forward that isn't well understood by the community at large but will be someday soon./proc seems like a trivial enough idea, but it is a step Plan 9 took toward getting to "everything is a file". Having threads and processes both as particular instances of a more general context of execution is a huge change to the Unix core, but it's also pretty much an accepted idea nowadays.
In fact, so much has changed that I would argue the question is somewhat spurious. We keep implementing Unix because "Unix" keeps changing and evolving.
It isn't simply implementation details; the process model, namespace, and filesysem are all very different beasts philosophically and theoretically on a modern Linux OS from what they were in Unix 10 years ago.
Think about this: with ReiserFS, you not only have things like journalling and wandering logs, but you have efficient small files and attributes, atomic updates to the fs, and other things that make replacing the database with the filesystem and other dramatic user-level changes much more appealing. In fact, the Unix-style directory tree is just a plugin in ReiserFS.
With the clone() system call, you can create execution contexts that share memory, file descriptors, file system namespaces, signal handlers, etc. You can share all, some, or none of those things. Traditional Unix processes (and the more recent thread concept) are just specific instances of a newer and very innovative replacement. Indeed, fork() is just a wrapper around clone.
The list goes on, but the point is simple: all of the core OS components are dramatically different from what they were in Unix, and I mean that at an OS theory level, not a mere implementation level.
In other words, real, core innovation is happening inside the Unix family. There are, in fact, actively developed non-Unix OSes; Hurd, Plan 9, and Xandos come to mind. They aren't amazingly popular, but they do have some support. I honestly think the real reason they aren't amazingly popular is that the kind of innovation that a ground-up OS rewrite allows IS actually actively done inside of the Unix family as well.
Well, as a Canadian who lives in Toronto (one of the country's largest population centres), I haven't heard ANYONE say 'aboot', EVER, except when quoting South Park. 'Eh?' plenty of times, and I even catch myself saying it once in a while, but 'aboot' never. Perhaps the Newfies say it that way, but I'd want a Newfie to confirm it. Have you ever travelled in Canada and heard 'aboot' yourself, or had someone you know directly (not a friend-of-a-friend) tell you they heard it?
I grew up in Maine. Plenty of visiting Nova Scotians said "aboot". We have one at work here who says it.
Perfect for colonization of other planets. If each human being has their own IP, then we would need to pack a whole bunch of planets to require more than that!
IPv6 might work, but remember the comment from the Linux kernel about TCP:
Note that 120 sec is defined in the protocol as the maximum possible RTT. I guess we'll have to use something other than TCP to talk to the University of Mars.
Slashdot Mirror
we also only have one Radio
and it's spelled "Clear Channel"
There are no anonymous functions above (Python doesn't really support them, which was a part of what I said in the above post). I have no idea if Javascript supports dynamic functions (if so, it's got plenty of company); I was simply responding to the assertion that Python doesn't.
Plenty of languages do support dynamic function creation. Scheme, smalltalk, and lisp are good non-python examples.
Sumner
Yeah, but I shouldn't have to use a separate tool. If it's a good idea to run such checks -- and, IMHO, it always is -- it should be built in to the standard language.
Think about it this way: There is no compile phase for your program. If you want to run lint, you can. If not, you don't have to. But it's not an "additional step" relative to a statically typed language.
And there are good reasons not to lint, many of them the same reasons that you would pick a dynamically typed language in the first place. I lint at the least before any code is checked in (our repository enforces that--you can't check in any code that isn't pylint-clean), but for rapid prototyping and testing it's not necessarily worth it.
(Pylint can even enforce policy, like making sure naming conventions, formatting conventions, etc are followed)
In a statically typed language I agree with keepin g the warning levels cranked up at all times. Since you can only test your code at points where static analysis is possible, you may as well not do it half-assed.
And this shows you don't know squat about Lisp. Lisp is not merely a functional language
I never said it was. I said that Python wasn't.
Both of them are multi-paradigm languages, but Python's support for functional programming is weaker than Lisp's. Still stronger than, say, Java's, but that's not saying much.
(and Python is even worse at pattern-driven programming)
you've confused dynamic typing with weak typing. Python is weakly typed and java is strongly typed. Both languages have strong dynamic typing.
Wrong. Strong and static are orthogonal. Static vs. dynamic refers to whether the language does type checking at compile time or at run time. Weak vs. strong refers to whether the type system can be circumvented or whether operations are type-safe.
Both properties are continuums, not booleans. It's reasonable to say:
C's typing is weak and static.
C++'s typing is weak and static
Java's is strong and static
ML's is strong and static
Tcl's is weak and dynamic
Python's is strong and dynamic.
BUT:
C++ has stronger typing than C, and it has rtti and other mechanisms to do dynamic type checking at runtime. But it's basically weakly typed in the realm of all languages, and it's basically statically typed.
Java is more weakly typed than ML, but it's still basically strongly typed. It's more dynamically typed than Ada, but it's still basically statically typed.
A decent lint (pylint, pychecker) will catch those typos before you run the code.
Its the type-checking stupid.
...but you have it wrong. First, Python _is_ strongly typed. It is not statically typed. The two concepts are orthogonal (e.g. C is statically typed but not strongly typed).
Absolutely...
I love Python. But I've shot myself in the foot enough times, with dynamic typing, to realize that strong typing is better for many things
Second, for many problem domains--especially the development of large web applications--dynamic typing has huge advantages over static typing.
And third, if you're dead-set on static typing, consider a language with type inference and _very_ strong typing (e.g. ML, Haskell, or Dylan -- ocaml is a very nice ML implementation)
IOW, typing is a huge factor. But it is not a better/worse thing except relative to certain problem domains.
Name me ONE TASK that Python (or Java) can do that the other can't.
Both are turing complete, and you could implement a Python interpreter in Java or vice-versa. If "it's possible somehow" is your measure, then there's no reason to choose Java over assembly.
In the end, it comes down to this: what is your personal coding style? What sort of syntax are you most comfortable with?
Syntax is largely irrelevant, people learn it quickly. Much more important are things like:
* Do I have strong typing or not? (Python, Java, ML, Ada vs C, C++, Tcl)
* Do I have dynamic typing or static (Python, Lisp, Tcl vs. Ada, C, Java, ML)
* How good is the language I'm using at modelling the problem I'm trying to solve?
* How good is the language at expressing things clearly and concisely
* How easy is it to reuse code/read code written by others/maintain large systems
Things like functional programming, pattern matching (NOT regex matching of strings, but real ML-style pattern matching), object orientation, metaprogramming, dynamic code generation, hygienic macros, the type model, etc all have REAL affects on how easily and elegantly you can solve a problem.
Less sexy but equally useful are details like "are flexible mappings a language feature or a library add-on", which seems trivial but makes a huge difference in practice.
Some of those features are very important when doing certain things and nearly useless when doing other things.
But programming languages definitely CAN be "better" than each other with respect to certain problem domains, and Python and Java differ in one of the most fundamental ways there is (more fundamental than e.g language-level support for object oriented programming, in my opinion) in that Java is statically typed and Python is dynamically typed.
Macros are not metaprogramming and macros cannot do everything that metaprogramming can. Go read up on metaprogramming.
(Python doesn't even _have_ macros, but it certainly has metaprogramming)
I know that Python has some very nice features (I read the tutorial) but it's hardly the sort of paradigm shift
static typing vs. dynamic typing is one of the MOST fundamental differences between programming languages. It has a tremendous effect on how you approach software design and how you engineer large systems.
Python is hardly the first dynamic language out there, but Paul knows that quite well.
To me, thats a very strange statement. The standard library of Java is, IMHO, one of the strongest around.
Ugh. Java as a language is rather nice (for a statically typed, non type-inferred language). The standard library is pretty unwieldy and inconsistent, though; I find myself fighting against the library more often than working with it.
Python would just use:
for Object in Collection:
Object.DoSomething()
In theory, Python is different from Lisp in a lot of ways. It's really not a functional language, though it does allow more flexibility in that direction than many basically OO languages.
In practice, I often find myself using a lot of dynamic functional techniques when I'm programming in Python.
You're correct about anonymous functions, but it's trivial to create named functions on the fly in Python. They can't be anonymous, but you can reuse the name immediately (either after the function isn't needed or after storing it in a dictionary or something). (Underscores addes since slashdot mangles whitespace)
Don't really see how you can compare a scripting language with an OO development language
... def __add__(self, b): ... if self==2: ... return self ... return int.__add__(self, b) ...
Which is which? Python is at least as OO as java. Even ints are objects.
>>> a=2
>>> a+1
3
>>> a.__add__(1) # used by + operator
3
>>> class my_int(int):
>>> a=my_int(2)
>>> a+1
2
>>> a+2
2
>>> a=my_int(1)
>>> a+1
2
>>> a+2
3
Does anyone really do anything other than just blindly hit "yes" when presented with a new host identification string?
If I know the machine just got wiped out or replaced, I'll hit yes. Otherwise, I'll investigate via outside channels. I've uncovered more than one DNS problem by investigating those messages.
Note that Linus did a 180 on "Linux Threads" versus "POSIX Threads" because Linux vendors wanted portability
Actually, he quite rightly didn't want to implement POSIX threads in the kernel originally, but went for a much more flexible Plan-9 style clone() call originally.
He never "did a 180" on this, either. He originally wanted a userspace implementation on top of Posix threads, which is what Xavier Leroy's LinuxThreads package was. Then Ingo cam along and made another implementation in userspace called NPTL. During the process of designing it he discovered that a few features at the kernel level (most notably futexes and the CLONE_DETACHED option) could help tremendously. futexes are useful for many things outside of Posix threads (Linus insisted on making a generic mutual exclusion mechanism rather than one that's pthread-specific), and CLONE_DETACHED is no different from similar flags that had been added before.
In short, Linus merely switched his endorsement from one implementation of pthreads at the userspace level to another. Had Xavier Leroy come up with a fast kernel mutex implementation, Linus probably would have accepted that as well. The original idea, though--that of using a much more general (and flexible, and easier to maintain) clone() call rather than implementing Posix threads at the kernel level--has not changed at all. In fact, at least some Java implementations use the native Linux threads without the POSIX wrappers, as do certain web servers.
This is different from the GNU/Linux argument, which is about complete distributions.
Saying the OS is Linux-like is completely reasonable given that most CS people consider OS to mean roughly "The minimal system that interfaces to the hardware". The only major OS component of a standard Linux distribution that isn't part of Linux is graphics drives provided by the X server; arguably, init and the shell could be included, but the amount of GNU code is certainly FAR smaller than the amount of Linux or X11 code in the OS itself, and certainly a lot of people use tcsh, zsh, or another shell.
There's a case for calling the complete distribution GNU/Linux, but not much of one at the OS level.
And there isn't much of a case for saying that UNIX is a Linux-like system as a whole (yet).
See, e.g., the Free Online Dictionary of Computing:
(OS) The low-level software which handles the interface to peripheral hardware, schedules tasks, allocates storage, and presents a default interface to the user when no application program is running.
Or the Jargon File:
operating system: n. [techspeak] (Often abbreviated 'OS') The foundation software of a machine; that which schedules tasks, allocates storage, and presents a default interface to the user between applications.
I don't remember there I read this, but someone once explained that while *BSD isn't trademark UNIX, it definitely is genetic Unix. Linux, on the other hand, isn't Unix at all, but merely a workalike
To my mind, Unix is 3 things; an OS implentation, a trademark, and an OS family. BSD is the third and first, Solaris is all 3. Linux is the latter. I can't see any good reason that Linux would want the 1st or 2nd. POSIX certification seems much more useful, since (at least historically) being trademark Unix doesn't make many strong guarantees about your behavior--Xenix still had major differences from "real Unix" even after SCO had it and was legally calling it Unix.
However, if it was automated, either that the distro set such things up for every user, or there would be a good tool
/home/joe/bin/mozilla that automagically ran mozilla as joe (similar for pine), and updated the Gnome configuration to use those services, would that be sufficient? (along with little things like symlinking ~/incoming/mozilla to ~joe-mozilla/incoming so that you could save files)
What counts as good?
e.g. if there was a JailService script where you could say:
sudo JailService mozilla joe-mozilla
sudo JailService pine joe-pine
and it set up the user accounts for that, copied over configs, added
would that be enough to get you to use it?
This is really something that distros should have as an option out of the box, at least for the browser and mail reader.
given everything I've heard about production code "going gold" while still rough polished brass, that's going to be a lot of third party SUID security holes. I'd say that the difference in protection quality amounts only to guarding against local user ignorance/stupidity...
I disagree, strongly. Limiting the window of time when root code is running and its exposure to inputs from malicious sources can be extremely important in general, and in many cases may be "good enough". Imagine the common case of a game that requires Admin privs to implement some copy protection scheme, where the game is a multiplayer networked game.
If the game is run as Administrator, then any remote exploit in the game elevates to Admin privs on the local machine.
If the game uses a small suid helper to do some copy protection stuff at startup, the suid helper can exit before any network code is started. Remote exploits are limited to the privs of the user.
The suid program may even be buggy as heck itself, but if it never takes input that might be from a malicious source then a fairly class of exploits are protected against.
Even in UNIX, SUID files are one of the things you need to watch closely.
No doubt. But if the alternatives are running a large untrusted game as Admin or running a smaller untrusted helper program as Admin, at least the latter reduces the sheer size of code that the untrusted party could have gaping security holes in (as well as the window of time for an exploit).
Obviously if the untrusted party is malicious (rather than just a source of potentially unaudited, insecure code) then either option is going to give them Admin power full stop.
There's no reason to run every program under the same account; in particular, programs that deal with potentially malicious data a lot can benefit greatly from running as their own user.
On my machine at home, I run my email client, web browser, newsreader as seperate users (if I'm "joe", they'd run as "joe-mail", "joe-news", and "joe-www"). The mail and news are almost completely isolated in chroot jails; I have links to their data in my home dir (and I have full read/write access to them, but not vice-versa). So viruses in email could clobber my mail, but couldn't touch anything else.
The browser account is similar, but it has X11 access which has a lot more potential for havoc. I used to run the browser on vncserver, with a vncclient for that. That proved to be a bit too much of a pain for me.
Once the setup was done, the whole thing is transparent to the user (clicking the launch icons does the appropriate magic behind the scenes to run things as the other users).
You can even set up per-user firewall rules that (for instance) only allow the joe-mail account to connect to selected IMAP/POP/SMTP servers.
But I guess I'm curious as to why nearly all OS focus is on UNIX or a derivative? From Linus's knock off, to Mac moving to a UNIX core to even the pretty original BeOS. Why are we reinventing the wheel and not coming up with something completely new?
/proc seems like a trivial enough idea, but it is a step Plan 9 took toward getting to "everything is a file". Having threads and processes both as particular instances of a more general context of execution is a huge change to the Unix core, but it's also pretty much an accepted idea nowadays.
This is not a troll, I am just looking for the various opinions. Is UNIX the basis for everything non-Microsoft because it's the pinnacle of perfection? Or, like movie plots, did 1 person invent a good thing and everyone else just replicates it with their own flare?
Unix is 3 things, an OS implementation (AT&T Unix code), an OS family (Unix, BSD, Linux, etc), and a philosophy.
The implementation obviously changes with every member of the family, so I assume your question is something like "are we sure the Unix philosophy is good, and why do we keep reimplementing that instead of improving it?"
The philosophy comes down to a couple of ideas which are pretty well articulated these days (everything is a file, do one thing well, etc), but they weren't written down or even well-considered at the time the original implementation was written. They weren't even strictly adhered to (ioctls, anyone?), but even the original managed to stick to them most of the time.
That philosophy can be refined and extended, as was done with Plan 9.
Indeed, some MAJOR improvements have been introduced under the radar in modern Unices. Linux 2.6, for instance, has per-process namespaces, which is an incredible step forward that isn't well understood by the community at large but will be someday soon.
In fact, so much has changed that I would argue the question is somewhat spurious. We keep implementing Unix because "Unix" keeps changing and evolving.
It isn't simply implementation details; the process model, namespace, and filesysem are all very different beasts philosophically and theoretically on a modern Linux OS from what they were in Unix 10 years ago.
Think about this: with ReiserFS, you not only have things like journalling and wandering logs, but you have efficient small files and attributes, atomic updates to the fs, and other things that make replacing the database with the filesystem and other dramatic user-level changes much more appealing. In fact, the Unix-style directory tree is just a plugin in ReiserFS.
With the clone() system call, you can create execution contexts that share memory, file descriptors, file system namespaces, signal handlers, etc. You can share all, some, or none of those things. Traditional Unix processes (and the more recent thread concept) are just specific instances of a newer and very innovative replacement. Indeed, fork() is just a wrapper around clone.
The list goes on, but the point is simple: all of the core OS components are dramatically different from what they were in Unix, and I mean that at an OS theory level, not a mere implementation level.
In other words, real, core innovation is happening inside the Unix family. There are, in fact, actively developed non-Unix OSes; Hurd, Plan 9, and Xandos come to mind. They aren't amazingly popular, but they do have some support. I honestly think the real reason they aren't amazingly popular is that the kind of innovation that a ground-up OS rewrite allows IS actually actively done inside of the Unix family as well.
Well, as a Canadian who lives in Toronto (one of the country's largest population centres), I haven't heard ANYONE say 'aboot', EVER, except when quoting South Park. 'Eh?' plenty of times, and I even catch myself saying it once in a while, but 'aboot' never. Perhaps the Newfies say it that way, but I'd want a Newfie to confirm it. Have you ever travelled in Canada and heard 'aboot' yourself, or had someone you know directly (not a friend-of-a-friend) tell you they heard it?
I grew up in Maine. Plenty of visiting Nova Scotians said "aboot". We have one at work here who says it.
IPv6 might work, but remember the comment from the Linux kernel about TCP: