Re: Gentoo guys starting a fork of udev
Hello Kevin,
On Sun, Nov 18, 2012 at 09:51:22PM -0600, Kevin Toppins wrote:
> Just because something is very old, does not necessarily make it
> wrong, obsolete, or require that it be changed.
Correct. But on the other hand, just because something is 40 years
old, doesn't mean we're not allowed to rethink the idea and start from
scratch. A fresh breeze is always needed from time to time.
> The unix model stemmed from when computers were mainframes and single
> user systems had not been conceived.
Thank you for your lesson, but I think I already know that.
> Unix's design of minimal permissions was/is a good idea. Since not
> everything running reflects the mindset of just one person, it makes
> sense to isolate users from messing with one another. Or, to allow for
> some relative sanctuary while using the system with others logged in.
And this has to do with replacing sysvinit with a modern alternative
how? We still have user separation. In fact, we have even more
possibilities by being able to control what ressources single users
can use (cgroups) which is very important if you have a big cluster
with dozens of concurrent users.
> It worked well to keep the peace.
Again, that doesn't mean we're not allowed to rethink the idea. CRT
television sets, analogue broadcasting, steam engines, mechanic
typewriters, analogue photography, audio and video cassettes also
worked well for decades. Still, people have upgraded to newer
technologies when they became available.
> Computer viruses (really) emerged when microsoft threw that notion to
> the wind and made their os a single user system with unlimited power
> and no layers of permissions to protect the integrity of the system.
Well, no. You can have a single user operating system and still be
perfectly free of virusses. On the other hand, you can even have
virusses on Linux machines. An important factor of a successful virus
infection is social engineering. Even Windows can be safe when taking
the proper precautions and even without a virus scanner.
> It's like if the pentagon upgraded every united states government
> employee with the highest security clearance. Sure the spec ops guy
> has clearance. So does the janitor and the delivery guy as well. It's
> defcon 1 24/7.
Again, how is this related to systemd vs sysvinit? As I mentioned
already, systemd has even more features to ensure resource control and
security (fine-grained permissions for journalctl, for example).
> That is why viruses are so prevalent. That is the real reason.
No, virusses are prevalent because people open every file without
extra precautions. Even advanced users and administrators sometimes
happen to do that.
> So unix stayed with the idea of minimal permissions for 40 years. They
> still stay with it. So does linux.
It's getting tiresome. I suggest you just read up on systemd a bit
before you start your discussion. systemd is actually a huge
improvement over sysvinit regarding reliability and security. It's
designed with these considerations in mind.
> Just about every os I can think of that has some resistance to malware
> uses a security model somehow based on separation of permissions.
Well, Windows NT uses separation of permissions. Yet there is
malware. Same applies for MacOS X.
> If something makes sense, has a sound foundation, is concrete in its
> logic...... and does not involve some specific point in time in some
> way.....
>
> ...... then the passage of time does not invalidate that idea.
>
> That idea should be succeeded by a better idea.
>
> That idea should not be obsoleted simply because it's 30 years old.
sysvinit is not being replaced because it's 30 years old. It is being
replaced because it lacks features we need nowadays and it's simply
not reliable enough.
For example, sysvinit cannot prevent a process from forking away. Once
sysvinit has started a daemon, the daemon can pretty much do whatever
it wants provided it has enough permissions. On systemd, there are
means to prevent that.
Another thing is making sure that a daemon is actually
running. systemd always knows the state of a daemon and can restart
it, if necessary. I probably don't need to explain you why this is
important. You cannot do that with sysvinit. As an example, we're
using autofs5 here at the department and we constantly are having
trouble when the machine is rebooting and autofs was already started
before NIS was ready even after sysvinit has started it. The result is
that none of the autofs mounts work until autofs has been manually
restarted. On systemd, this won't happen, because systemd is aware of
the fact that NIS and rpcbind need to be up and running before autofs
can do anything sensible.
And thirdly, if you have very large file systems (we have a 30TB
hardware raid here, for example), filesystem checks can take
forever. If you reboot such a server and it needs to do an fs check,
it will be unavailable until the check has finished. With systemd, you
can just declare the filesystem as an automount [1] and the system
still boots while the filesystem checks are performed.
> We use the mathematics of relativity and trigonometry to make GPS work, btw.
>
> https://en.wikipedia.org/wiki/Pythagorean_theorem#History
Sticking to your chain of arguments: If physicists had been happy with
the theory aether [2], Einstein had never come up with special
relativity and GPS actually would never be able to work. The math
behind special relativity is just a little older than 100 years (annus
mirabilis is dated back to 1905), so it's actually something NEW.
The fact that GPS works is a result of PROGRESS.
Cheers,
Adrian
> [1] https://wiki.archlinux.org/index.php/Systemd#Automount
> [2] http://en.wikipedia.org/wiki/Luminiferous_aether
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: