In order to do this, you would need
either some pretty amazing type inference, or variables with declared static typing. There is some work on this (Types-SIG). The main change would be that you can't change the type of a var at runtime, eg
a = "Popsicle"
a = len(a)
would be disallowed, as a would be presumed to only hold strings. This doesn't happen too much anyway, as it is confusing..
Unfortunately, a strap-on security model
is always very sucky. Look at ACLs on any
unix or even NT. Your model sounds like a
typical hacked up pile of shite.
What you want is capabilities.
See www.eros-os.org
Basically - a capability is an
unforgeable object reference.
In a true capability system,
that is the only way to do
anything outside your own address space.
This allows anyone to implement a very
simple security model which is much
easier to verify. It also gets
rid of all the dumb ass home grown
authentication systems on unix. (ie Each
app authenticating people in a funny way)
Some complete monkeys thought that in London, it would be pronounced cunt.
As a Londoner, I can assure the aforementioned monkeys that no London accent would cause this...
It used to be thought *good* to mess with peoples sensibilities - see fsck - but now its gone so far in the other direction that we've started to make up imaginary cultural issues to avoid.
Hm... I have a hard time believing you actually read my comment. Find where I said good quality closed source was impossible... clearly its not.
There are also a lot of strange perl scripts floating around on freshmeat that no one should trust. The cost of evaluating one of these silly programs is far greater than the cost of reimplementation. I am talking about things where the cost of evaluation is outweighed by the cost of reimplementation. Eg an operating system, C compiler, mail server, etc etc.
What I said was that you get no *legally enforcable* guarantee that closed source software will even work at all. General opinion is that software will continually break, and if you trusted some software to do a job, it is your fault. Lots of *huge* software contracts are not fulfilled in any meaningful sense (look at eg EDS' history), and it is only very rarely the seller is held liable. In this atmosphere it makes practically no sense to choose a closed source alternative when an open one does the job, even less proficiently. You are just asking for pain needlessly. You are taking the risk that you will have to go to court and lose. Some people try to construe this as an advantage of closed source software: The "who do you sue" argument. This view takes no account of the actual likelyhood of winning a case. If you feel the need to pay someone, pay someone to make the improvements you want. The only time when closed software makes sense nowadays is when there is no open alternative.
So if you look at it from an economic perspective, a closed source solution has a huge risk attached - that it will not do the job, and your entire investment will be written off. An open source solution has a smaller risk - that it can not be modified within budget to do the job. For these reasons, I only choose a closed source solution when absolutely necessary.
I agree with your first point that distributed internet style coding is not like pair programming. Of course they could be combined pretty handily.
Your next bit...
Open source doesn't seem to work any better than closed...
I don't know how you made this assessment... Open source is not a panacea, but if you are actually relying on any code, its nice to have one of two things:
a) The code.
b) Someone to blame. Presumably they have the code.
Unfortunately, b) no longer works. It is now taken as read that software breaks, so it is hard to get a court to assign any damages when it does. So a) is better than nothing.
Almost everytime I use a closed source system, there is something about it that is broken. I want to fix it, but I can't. With an open source system, it can be fixed. To me, this does seem to lead to open source working better in the limit...
Of course there are a lot of useful proprietary programs out there. There are a lot of useful open ones too. And as time goes on, it seems like the number of proprietary ones that have no open equivalent is decreasing.
Re the money thing. Economic trends are dictated by what is better for consumers, not producers. The consumers choose where to spend the money...or not. If there is no need to spend money, it won't get spent. You can finish that thought.
(Some have also criticised The GIMP for the multitude of windows it uses. Would it be better that The GIMP would open one huge window filling the entire screen (making you unable to do anything else on that desktop) and include a built-in window manager (which of course is not the one you would like to use) to manage the smaller windows, as is in Ph*t*sh*p and StarOffice?)
Maybe it would be better if the gimp could have a ui which was just a bit like gnome and kde programs? Menu bar, toolbars, etc etc.
How do you make a photo storage CD which can be viewed on a DVD player? I've been wondering about this.
Do all DVD players support PhotoCD, or do you use VCD 2 or VCD 1?
Eh?
To implement a CORBA client, your client and server must both implement enough of the CORBA spec to talk to each other. Now it can all be done dynamically, ie look up the interface in the interface repository and use DII to call things. Or it can be done with stubs.
None of the server is embedded. It is
*possible* to generate stubs from the
*interface definition*.
To implement a SOAP client, our client and server must both implement enough of the SOAP spec to talk to each other. Now it can all be done dynaically, by downloading the xml defining the interface. Currently I know of no work on stubs, though I'm sure it must be possible.
So all SOAP does is have a less efficient
encoding( may be alleviated by some kind of
compression), and emphasises the transport layer rather than the interface definition.
It isn't a magic thing, it doesn't write programs for you.
So what does this mean? It means you have to write a lot of XML with your program. This might be easier to understand than CORBA, and lead to more people "getting" it and using it. That is its only real strength...but that, along with industry backing, might be enough.
Maybe because minix is utter shite?
I just had to dig around in the kernel, fs,
and mm sources, in order to implemnet a debugger for a uni project. It is not nice. A particularly scummy message passing scheme, sicko macros everywhere, global variables for everything! *shudder*
I judge this from also having messed about with
Linux, eros, and FreeBSD kernel source. All those were nicer. A lot nicer. And eros is in C++, so that is an acheivement.
mm& fs are misnamed - they should be called "Random system call task 1" and
"Random System call task 2".
Honestly. Minix is not suitable for *any* use other than torturing university students.
A benefit of linux is that you do not have to threaten people with failure of a course/loss of future monetary income/etc to get them to mess with it.
Well, this is ok if all you are interested in
is system security. Ie you don't want to get rooted.
But to be honest, I don't trust most programs I run with my own files. I don't want the huge unaudited mozilla to be able to write to my thesis.
Thats where unix can not be fixed in an efficient way. You need to fundamentally break posix, unfortunately.
Yep, this is possible - look at qmail,
to be secure, there are lots of user accounts.
Each bit runs under a different one.
Unfortuanately, its just a hack. To add users
you need root access, ie ultimate boredom for root.
Or package management nightmares with coordinating uids. Maybe this could be solved with a better PAM plugin.
However, if you make a new user for
every app automatic, kernel checks go
like this:
userspace:
system_call(arg1,arg2,...);
kernelspace:
user = current_program->user;
do_check_on_whether_user_is_allowed(user);
this could be:
looking through a set of acls on a file.
checking a privelege bit.
checking if the uid is 0.
do_the_job();
in a cap based os:
userspace1:
call(cap, arg1, arg2,....)
kernelspace call handler:
dest = get_dest(cap);
copy_args_to_dest(dest);
schedule_dest();
(dest can be kernel or user task)
dest:
do_the_job();
So in a cap based os the possesion of a cap means you are allowed to do something. No funky checks.
The checks are done in userspace (no kernel policy)
when you are given the caps.
so doing this in a unixy os would be drastically inefficient if it was done system wide.
Well, this is another nice hack.
Hacks to the unix security model are nothing new,
and are also nothing interesting.
Posix ACLs, privilege bits, online
tripwire style things, ptrace abusers,
are all pretty damn skanky.
And I would prefer an elegant unix with
lax security that I know the limits of,
to a clunky add on laden unix with no
real coherent security model.
Of course, an OS that used a capability model
would be better...
You seem to have got the userspace/kernelspace split mixed up with the root/normal user split.
The first is a difference in memory mapping. When you are running a normal program, your own memory is mapped appropriately as some of readable, writable, and executable. The kernel is always mapped non readable, non writable, and non executable. When entering the kernel ( eg system call, page fault, interrupt), the kernel memory is changed to be readable, writable, and executable.
The second is how the kernel responds to system calls. When a system call is called, if it is a privileged operation, the kernel will perform a check to see if the program is allowed to do this.
In old unix, this was often just a check to see if the uid in the process control structure was 0. In linux, it is usually a check of a privelege bit ( evilly called capabilities by posix and linux). So different processes can have different set of priveleges.
So, in unix, you su to root. This doesn't make you run in kernel mode. You are still running just like a normal user. The only difference is, when you do a system call, the kernel grants you a special privelege to bypass normal security checks.
This is wierdo special casing. Not nice.
In a capability system, a token is passed along with any other arguments to a system call. This token proves to the kernel that you are allowed to do the call you asked for. No wierd special cases. No acl systems or even the concept of a "user" in the kernel.
This can and is being implemented on x86. See eros - www.eros-os.org
Unfortunately, whilst unix does kick ass in many respects, there are a few deficiencies when it comes to security. Here are a few that come to mind:
1) All programs you run are trusted with all files you have access to.
2) All programs are also given a default set of actions they can perform, eg open random connections to the internet. This is nice for leaking information. This can be amelorated via so called posix capabilities. These are more properly called privelege bits as in VMS.
3) Global filesystem. Everyone can see the filesystem./tmp can leak a lot of information.
Chroot may help. Plan 9 style namespaces are better too. Better would be to take the human namespace out of the kernel and only give it to programs that need it.
probably lots of other things. Basically unix was designed when everything you ran on your computer was written by yourself of someone you knew and trusted. And then commercial unix just got featuritis. It would probably not be good to declare it the one true operating system.
OpenBSD is still based on the fallacy that affects unix and all clones. That you trust every program you run as much as you trust yourself. Ie security is done at a per account granularity.
Any program you run can do anything to every file you have write access to, and can also leak information by default to anyone on the internet. Not good. This means a very large trusted code base, which is a bad thing. The set of code which need to be trusted (ie the kernel and very few programs) should be as small as possible.
There are some approaches to improving security. Capabilty models look like the best hope for the future. This comment is too small to hold a reasonable explanation - take a look at http://www.eros-os.org .
Don't get me wrong, OpenBSD is a good firewall and general unix server platform, but its security model is limited by posix compliance.
People do pay for stuff. No one needs to buy CDs, and haven't had to since they were introduced! Anyone could go down the library, tape it, and take it back. Or buy it, tape it, take it back and say "It was a present and they already had it". Or for the lazy, buy a $2 CDR or tape bootleg from a market stall.
Of course, if everyone had done this, then no RIAA music would have been produced. What does that tell you? People buy stuff they like!
And wait a moment. You are saying that stuff like Vanilla Ice wouldn't happen in a micropayment world. How is that a bad thing?
95% of the music out there <i>doesn't sell</i>.
There are a lot more independant artists out there than RIAA ones.
Good point...however, I think that the ideas will go in the other direction. Ad filtering for TV.
Imagine a Tivo-alike with a button on the remote that says "AD". It functions like fast forward, but when a certain number of people press it, it gets in to a database of ad times. This can then be used to mark the ads on everyone elses recordings.
Problems:
A trust network could be used to stop abuse (by paid advertisers/TV networks employees!) And maybe it should be peer to peer so it can't be shut down easily.
So TV ads may be as useless as web ads soon.
So where does the money for content come from? Well it *is* going to happen, and no one is going to change the morals of a generation by moaning that rich guys are losing money. So a new model is needed.
The BBC in the UK is funded by a mandatory subscription/licence fee/tax or whatever you want to call it. Very few people in here in the UK find this objectionable. However, if there was no other content, I'm sure the BBC would start producing rubbish.
Subscription? Maybe.
The Street Performer Protocol is my favorite. The corps will have to get desparate before they try it though...
Slashdot Mirror
What about geothermal?
Always seemed pretty sensible to me...
anything wrong with it? Eh?
In order to do this, you would need
either some pretty amazing type inference, or variables with declared static typing. There is some work on this (Types-SIG). The main change would be that you can't change the type of a var at runtime, eg
a = "Popsicle"
a = len(a)
would be disallowed, as a would be presumed to only hold strings. This doesn't happen too much anyway, as it is confusing..
Sounds like it would be a porn centered
distribution... Divx and newsreading etc
in the default install!
Unfortunately, a strap-on security model
is always very sucky. Look at ACLs on any
unix or even NT. Your model sounds like a
typical hacked up pile of shite.
What you want is capabilities.
See www.eros-os.org
Basically - a capability is an
unforgeable object reference.
In a true capability system,
that is the only way to do
anything outside your own address space.
This allows anyone to implement a very
simple security model which is much
easier to verify. It also gets
rid of all the dumb ass home grown
authentication systems on unix. (ie Each
app authenticating people in a funny way)
Some complete monkeys thought that in London, it would be pronounced cunt.
As a Londoner, I can assure the aforementioned monkeys that no London accent would cause this...
It used to be thought *good* to mess with peoples sensibilities - see fsck - but now its gone so far in the other direction that we've started to make up imaginary cultural issues to avoid.
Duh.
Hm... I have a hard time believing you actually read my comment. Find where I said good quality closed source was impossible... clearly its not.
There are also a lot of strange perl scripts floating around on freshmeat that no one should trust. The cost of evaluating one of these silly programs is far greater than the cost of reimplementation. I am talking about things where the cost of evaluation is outweighed by the cost of reimplementation. Eg an operating system, C compiler, mail server, etc etc.
What I said was that you get no *legally enforcable* guarantee that closed source software will even work at all. General opinion is that software will continually break, and if you trusted some software to do a job, it is your fault. Lots of *huge* software contracts are not fulfilled in any meaningful sense (look at eg EDS' history), and it is only very rarely the seller is held liable. In this atmosphere it makes practically no sense to choose a closed source alternative when an open one does the job, even less proficiently. You are just asking for pain needlessly. You are taking the risk that you will have to go to court and lose. Some people try to construe this as an advantage of closed source software: The "who do you sue" argument. This view takes no account of the actual likelyhood of winning a case. If you feel the need to pay someone, pay someone to make the improvements you want. The only time when closed software makes sense nowadays is when there is no open alternative.
So if you look at it from an economic perspective, a closed source solution has a huge risk attached - that it will not do the job, and your entire investment will be written off. An open source solution has a smaller risk - that it can not be modified within budget to do the job. For these reasons, I only choose a closed source solution when absolutely necessary.
I agree with your first point that distributed internet style coding is not like pair programming. Of course they could be combined pretty handily.
Your next bit...
Open source doesn't seem to work any better than closed...
I don't know how you made this assessment... Open source is not a panacea, but if you are actually relying on any code, its nice to have one of two things:
a) The code.
b) Someone to blame. Presumably they have the code.
Unfortunately, b) no longer works. It is now taken as read that software breaks, so it is hard to get a court to assign any damages when it does. So a) is better than nothing.
Almost everytime I use a closed source system, there is something about it that is broken. I want to fix it, but I can't. With an open source system, it can be fixed. To me, this does seem to lead to open source working better in the limit...
Of course there are a lot of useful proprietary programs out there. There are a lot of useful open ones too. And as time goes on, it seems like the number of proprietary ones that have no open equivalent is decreasing.
Re the money thing. Economic trends are dictated by what is better for consumers, not producers. The consumers choose where to spend the money...or not. If there is no need to spend money, it won't get spent. You can finish that thought.
Look down the bottom of the page:
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2001 OSDN.
(Some have also criticised The GIMP for the multitude of windows it uses. Would it be better that The GIMP would open one huge window filling the entire screen (making you unable to do anything else on that desktop) and include a built-in window manager (which of course is not the one you would like to use) to manage the smaller windows, as is in Ph*t*sh*p and StarOffice?)
Maybe it would be better if the gimp could have a ui which was just a bit like gnome and kde programs? Menu bar, toolbars, etc etc.
How do you make a photo storage CD which can be viewed on a DVD player? I've been wondering about this.
Do all DVD players support PhotoCD, or do you use VCD 2 or VCD 1?
Eh?
I need to know!
I don't get this...
To implement a CORBA client, your client and server must both implement enough of the CORBA spec to talk to each other. Now it can all be done dynamically, ie look up the interface in the interface repository and use DII to call things. Or it can be done with stubs.
None of the server is embedded. It is
*possible* to generate stubs from the
*interface definition*.
To implement a SOAP client, our client and server must both implement enough of the SOAP spec to talk to each other. Now it can all be done dynaically, by downloading the xml defining the interface. Currently I know of no work on stubs, though I'm sure it must be possible.
So all SOAP does is have a less efficient
encoding( may be alleviated by some kind of
compression), and emphasises the transport layer rather than the interface definition.
It isn't a magic thing, it doesn't write programs for you.
So what does this mean? It means you have to write a lot of XML with your program. This might be easier to understand than CORBA, and lead to more people "getting" it and using it. That is its only real strength...but that, along with industry backing, might be enough.
Erm, most of the stuff I look at in my browser doesn't seem to be on my disk. Its on this wierd thing called the world wide web. Think!
Maybe because minix is utter shite?
I just had to dig around in the kernel, fs,
and mm sources, in order to implemnet a debugger for a uni project. It is not nice. A particularly scummy message passing scheme, sicko macros everywhere, global variables for everything! *shudder*
I judge this from also having messed about with
Linux, eros, and FreeBSD kernel source. All those were nicer. A lot nicer. And eros is in C++, so that is an acheivement.
mm& fs are misnamed - they should be called "Random system call task 1" and
"Random System call task 2".
Honestly. Minix is not suitable for *any* use other than torturing university students.
A benefit of linux is that you do not have to threaten people with failure of a course/loss of future monetary income/etc to get them to mess with it.
Well, this is ok if all you are interested in
is system security. Ie you don't want to get rooted.
But to be honest, I don't trust most programs I run with my own files. I don't want the huge unaudited mozilla to be able to write to my thesis.
Thats where unix can not be fixed in an efficient way. You need to fundamentally break posix, unfortunately.
Yep, this is possible - look at qmail,
....)
to be secure, there are lots of user accounts.
Each bit runs under a different one.
Unfortuanately, its just a hack. To add users
you need root access, ie ultimate boredom for root.
Or package management nightmares with coordinating uids. Maybe this could be solved with a better PAM plugin.
However, if you make a new user for
every app automatic, kernel checks go
like this:
userspace:
system_call(arg1,arg2,...);
kernelspace:
user = current_program->user;
do_check_on_whether_user_is_allowed(user);
this could be:
looking through a set of acls on a file.
checking a privelege bit.
checking if the uid is 0.
do_the_job();
in a cap based os:
userspace1:
call(cap, arg1, arg2,
kernelspace call handler:
dest = get_dest(cap);
copy_args_to_dest(dest);
schedule_dest();
(dest can be kernel or user task)
dest:
do_the_job();
So in a cap based os the possesion of a cap means you are allowed to do something. No funky checks.
The checks are done in userspace (no kernel policy)
when you are given the caps.
so doing this in a unixy os would be drastically inefficient if it was done system wide.
Well, this is another nice hack.
Hacks to the unix security model are nothing new,
and are also nothing interesting.
Posix ACLs, privilege bits, online
tripwire style things, ptrace abusers,
are all pretty damn skanky.
And I would prefer an elegant unix with
lax security that I know the limits of,
to a clunky add on laden unix with no
real coherent security model.
Of course, an OS that used a capability model
would be better...
Hm, you are quite silly.
Read it again. Stop worshipping at the altar of unix.
It is not perfect.
Typing from a unix system... damn , still no IE beating browsers yet!
Yes, thats a real nice hack. I am talking about a practical approach, not a nasty add on hack.
Ok.
You seem to have got the userspace/kernelspace split mixed up with the root/normal user split.
The first is a difference in memory mapping. When you are running a normal program, your own memory is mapped appropriately as some of readable, writable, and executable. The kernel is always mapped non readable, non writable, and non executable. When entering the kernel ( eg system call, page fault, interrupt), the kernel memory is changed to be readable, writable, and executable.
The second is how the kernel responds to system calls. When a system call is called, if it is a privileged operation, the kernel will perform a check to see if the program is allowed to do this.
In old unix, this was often just a check to see if the uid in the process control structure was 0. In linux, it is usually a check of a privelege bit ( evilly called capabilities by posix and linux). So different processes can have different set of priveleges.
So, in unix, you su to root. This doesn't make you run in kernel mode. You are still running just like a normal user. The only difference is, when you do a system call, the kernel grants you a special privelege to bypass normal security checks.
This is wierdo special casing. Not nice.
In a capability system, a token is passed along with any other arguments to a system call. This token proves to the kernel that you are allowed to do the call you asked for. No wierd special cases. No acl systems or even the concept of a "user" in the kernel.
This can and is being implemented on x86. See eros - www.eros-os.org
Well clearly unix.
But thats not the choice.
Its unix vs. writing a new os.
New OS wins for me.
Unfortunately, whilst unix does kick ass in many respects, there are a few deficiencies when it comes to security. Here are a few that come to mind:
/tmp can leak a lot of information.
1) All programs you run are trusted with all files you have access to.
2) All programs are also given a default set of actions they can perform, eg open random connections to the internet. This is nice for leaking information. This can be amelorated via so called posix capabilities. These are more properly called privelege bits as in VMS.
3) Global filesystem. Everyone can see the filesystem.
Chroot may help. Plan 9 style namespaces are better too. Better would be to take the human namespace out of the kernel and only give it to programs that need it.
probably lots of other things. Basically unix was designed when everything you ran on your computer was written by yourself of someone you knew and trusted. And then commercial unix just got featuritis. It would probably not be good to declare it the one true operating system.
OpenBSD is still based on the fallacy that affects unix and all clones. That you trust every program you run as much as you trust yourself. Ie security is done at a per account granularity.
Any program you run can do anything to every file you have write access to, and can also leak information by default to anyone on the internet. Not good. This means a very large trusted code base, which is a bad thing. The set of code which need to be trusted (ie the kernel and very few programs) should be as small as possible.
There are some approaches to improving security. Capabilty models look like the best hope for the future. This comment is too small to hold a reasonable explanation - take a look at http://www.eros-os.org .
Don't get me wrong, OpenBSD is a good firewall and general unix server platform, but its security model is limited by posix compliance.
Okay.
People do pay for stuff. No one needs to buy CDs, and haven't had to since they were introduced! Anyone could go down the library, tape it, and take it back. Or buy it, tape it, take it back and say "It was a present and they already had it". Or for the lazy, buy a $2 CDR or tape bootleg from a market stall.
Of course, if everyone had done this, then no RIAA music would have been produced. What does that tell you? People buy stuff they like!
And wait a moment. You are saying that stuff like Vanilla Ice wouldn't happen in a micropayment world. How is that a bad thing?
95% of the music out there <i>doesn't sell</i>.
There are a lot more independant artists out there than RIAA ones.
Good point...however, I think that the ideas will go in the other direction. Ad filtering for TV.
Imagine a Tivo-alike with a button on the remote that says "AD". It functions like fast forward, but when a certain number of people press it, it gets in to a database of ad times. This can then be used to mark the ads on everyone elses recordings.
Problems:
A trust network could be used to stop abuse (by paid advertisers/TV networks employees!) And maybe it should be peer to peer so it can't be shut down easily.
So TV ads may be as useless as web ads soon.
So where does the money for content come from? Well it *is* going to happen, and no one is going to change the morals of a generation by moaning that rich guys are losing money. So a new model is needed.
The BBC in the UK is funded by a mandatory subscription/licence fee/tax or whatever you want to call it. Very few people in here in the UK find this objectionable. However, if there was no other content, I'm sure the BBC would start producing rubbish.
Subscription? Maybe.
The Street Performer Protocol is my favorite. The corps will have to get desparate before they try it though...
Erm, from what you say, you agree with the original poster. So why is this phrased as an opposing viewpoint?