Having said that, if 3rd parties were paying out hundreds of thousands of dollars to Epic, what were they getting for their money? For that kind of cash I would expect to have an Epic developer or two supporting and working with me full time to make it work.
Ermm... how much do you think a decent developer costs? Even if you payed $500,000 for the engine, if you got two core engine developers for two years that could easily be half of what you payed (note, I'm talking about what it costs Epic, not what the developer will get as net pay).
I assumed "etc." included Qt. Don't want to forget about the KDE crowd!
So a series that only included bindings to a single widget set should have in the implicit expansion a completely different widget set? The "etc." stood for the perl elisp etc. (hope you can see where this is going now) bindings that I didn't list.
So which is the standard? GTK or Qt?
Let's see, GTK is the default in Fedora and Ubuntu. Mono/C# and Java basically only have GTK bindings. For a commercial entity (which you said you were) you have to pay for Qt and don't have to pay for GTK... I'm kind of assuming, again, but this doesn't seem that hard of a question to me.
Linux's lack of a standard GUI layer in the OS - modern menus, buttons, lists, even windows - is the primary issue for us.
I'm sorry, what? This isn't 1995 anymore where Motif and libXaw were the main GUI toolkits. gtk+, pygtk, gtk#, SWT, etc. are shipped in every distribution containing all the common widgets and are free to use. Maybe you mean your visual-studio developers can't use anything else? Well have fun in hell with that snowball waiting for MS to port the apps. you've locked yourself into.
And as counter argument I give you God of War 1 and 2, both of which have naked breasts at multiple points. And both have "sex games" to earn experience.
Let's face it video game ratings are just done using a bag of popcorn a 10 sided die factoring in the phase of the moon, just Film ratings.
When it came to the area with the close-the-toilet-door scene, it was ridiculous. Not only was that event nearly impossible
Really? I didn't think that part was *that* hard - and I'm most certainly a casual gamer (I usually only play 2 or 3 times per month if that often.)
Well I had a similar problem, although the other events were ok so I could finish the level. The problem for me was that the intuitive interface was for you to "push" where the door was. What you actually needed to do was "shake" where the door would be, if closed. After that revelation (which took _many_ tries, and random internet searches) it was about par.
re: copyright, yes you can declare software as public domain in the USA. You can't have copyright without public domain, that is, copyright is defined as materials not in the public domain [and vice versa].
Yes, but AIUI there's no legal way, in the US, to move something from being in the copyright bucket to being in the "public domain" bucket... without waiting for death + 30^W 50 ^W 70 years. Just saying "this code is public domain" leaves you open to warranty claims and leaves your users open to being sued by your estate for copyright infringement. Just BSD+MIT+whatever multi-license it, it does the same thing but protects everyone involved.
It's not quite so simple, deducting interest from your mortgage only reduces the rate by roughly 1% (given a sane rate). Also it's general financial advise to diversify, so even though it might not be the "theoretically best" option putting a small percentage of your investments into your low interest debt. isn't a bad thing.
The difference, though, is that RedHat is a company, which wants to pay for certification so they can use it to market their product.
Actually that's just wrong. Red Hat doesn't really pay for them, the HW vendors like HP and IBM do... so Trusted*BSD should easily be able to get that certification, if people wanted to buy systems with it.
But in my opinion the real major difference is that Fedora is a usable general purpose OS with MAC capabilities, this is like if FreeBSD shipped all of the code for MAC and TrustedBSD just shipped a policy file to enable it. In fact it's better than that, because Fedora ships with a "simpler policy" using those same code paths that is helpful and usable by normal people (incl. things like generic rsync/cp/mv/tar/etc. support). This means that it's all much better tested than other MAC implementations, IMO. This was/is a huge effort on Red Hat's part, and is currently unequaled on non-Linux platforms.
I really would like to hear more about these 'hard facts' of programming...it makes it sound like it is harder to program for Linux - is this supposed to be a good thing? However, I don't believe this, and suspect it's the usual macho Linux bullshit that some F/OSS advocates seem to be afflicted with.
Being optimistic I'm hoping what he really meant was something like: "Linux and win32 are very different, you can't instantly program for one just because you've done so on the other. To add even more fun to the mix all your favourite tools won't be there if you go from win32 to Linux."
Although this works just as badly the other way around, all of the Linux software I've seen "ported" to win32 has just as many problems because win32 is not even close to Linux.
But you're probably right, it was probably just macho my X is better bullshit.
Unfortunately, there's also a whole bunch of people who naively thought permissive mode would only log and not interfere with anything, spent two days troubleshooting some problem, finally _disabled_ SELinux and had it work perfectly from the default two days ago.
To be fair this is almost always not directly the fault of SELinux, the Linux kernel has a few newer "security" options like "allow apps. to mmap() onto page 0" which they default to "off" for compatibility but SELinux defaults to "on" so that it can deny them per. process (SELinux, like most security software, doesn't like to grant privilages but just remove them).
I appreciate that it doesn't help you when you are trying to debug the problem though.
So, setcon() is more secure than change_hat() because you don't use it and don't document it?:-)
No it isn't a security problem because it isn't said/assumed/documented to be secure when we know it isn't. Yes, SELinux could have setcon() used to go from httpd to httpd_mod_perl and back again... but it would be smoke and mirrors, and would just confuse people instead of working on a real solution to the problem. change_hat() is a bug because you are advertising it to be secure which it clearly isn't. As with a lot of AppArmor it would be much more palatable if you advertised what it did, and not what you want it to do (of course then people aren't going to want to use it to do things it can't... but that's life).
If it is labeled firefox_net_untrusted_t then no sane program will trust it. Purist tranquility requires that you shut down to re-label, and non-purist at least requires super-user and unconfined_t to re-label.
I'm not sure where you get this from, maybe you should try using/understanding SELinux? Normal users regularly change permissions (via. the change context commands: chcon or nautilus) so that httpd/samba/ftp can/cannot read files. Much as they change permissions (via. the unix mode commands: chmod and nautilus) to make things readable/executable etc.
The AppArmor equivalent of this is to 'reclassify' your downloaded objects by moving them from your Download folder to some other place, where other programs are allowed to access it.
Again, you speak as though that's a good thing... as though that maps to any kind of normal behaviour that any sane person would expect.
That is pure BS. AppArmor allows you to write your profiles by hand, or via the learning tool, and to interleave the two. SELinux also allows both hand-authored policies or audit-to-allow generated policies, so the security confinement of each system is identical with respect to 'WtF?' behavior of applications.
The main difference is that AppArmor's learning mode actually works well:)
No the difference is that you, and AppArmor supporters in general, keep saying the GUI learning tools is "the one true way" often at least heavily implying you don't need to do anything else if not outright saying SELinux sucks because you can't just run one tool and be done. So, yeh, technically with AppArmor you can "have it be secure, just write/review it all by hand" in the real world that isn't happening with AppArmor profiles.
The SELinux people keep trying to inform everyone that no matter what you do you need to "write" most of the policy seperately from the application. Sure, you can have GUI tools create most/all of it for you (Eg. select a drop down for: I'd like a normal networking daemon that binds to port X, and logs data in directory Y). You can even do "fixups", where you react to a couple of messages like "X permission is disallowed for Y" by a command that changes the policies. This way you find out thunderbird wants setuid() not when someone sees that permission granted in it's profile and thinks "wtf, does someone own my machine", but when someone sees that permission denied and thinks "wtf, but who cares it's denied".
It took SELinux a while too, and they didn't have to contend with AppArmor advocates complaining about their model:)
No, we just have to contend with AppArmor advocates on every news site whenever SELinux is mentioned... often bending the truth more than a little. Also are you seriously trying to suggest that the only kernel developers complaining about your design are SELinux advocates? Mind you I guess Richard Gooch started to get a little paranoid too, at the end -- I only hope AppArmor doesn't cause as much pain before it dies.
Not at all, setcon() has been around for a long time it's just not advertised/used for this case explicitly because it's not secure. The fact you added a stupid cookie value doesn't make change_hat secure, and the fact you are advocating it as secure means that it's insecurity is a bug.
For instance you keep advocating it for "mod_perl security"... except what you mean is that "if you are really lucky mod_perl will be more confined than the rest of apache-httpd, but then again maybe not", and what a lot of people want from mod_perl security is for two different users of apache-httpd using perl code to be "secure/confined from each other, and from the web server itself"... change_hat provides neither of these.
We do ship Firefox profiles with every SUSE release. You'll find them in/etc/apparmor/profiles/extras
But, as I said, do they those profiles do anything useful. With SELinux you can have firefox allowed to write files everywhere you can, but they'll be labeled firefox_net_untrusted_t or whatever. You won't be allowed to overwrite files that haven't been previously downloaded from firefox, you can disable exec privilages on downloaded executables etc. etc. AIUI AppArmor can do none of this "higher level, useful, things" all it can do is blanket "firefox can't write files in ~/home, etc.".
SELinux advocates love to throw that at me, but it makes no sense. If you want to know wny Thunderbird, or any given application, does a silly thing, go ask the developers of that program. AppArmor just faithfully noted that it did it. How is this a problem with AppArmor?
AppArmor in learning mode is actually quite good at generating 'WtF?' moments as you observe what your software is doing. This is a strength of AppArmor, not a defect.
Of course it makes sense, as long as you continually advocate that the "best" way to generate policies is to run applications and allow them to do everything that they are doing... that isn't confinment. SELinux also generates WtF? moments, it just also protects you while it is telling you your apps. are on crack (or using generic code which needs privs they don't, like password checking which opens/etc/shadow directly but falls back to using a secure helper -- but lucky AppArmor users just get all their passwords stolen instead).
I'm sorry, but your review is more than a year old. For example: it talks about patching the kernel, which isn't necessary anymore (since it uses LSM now).
But it's still not upstream, and that's not because the developers have some political/technical reason... just that it's so horrible the majority of the upstream developers don't want it. SELinux has been in the upstream kernel for years, and so is distributed by basically everybody now. Is supported by at least 4 different distributions.
So, yeh, well done... you don't need to patch anymore, you just need to load a module that has to be compatible with your kernel and is likely to always be distributed seperately and thus. by a very small number of distributors. Sounds great!
This is a mis-characterization of the AppArmor model. AppArmor confines the processes to the filepaths you tell it to... this is like if some random program created a link to/etc/passwd (say, to do some weird locking) the new filename would automatically get permissions of 666 or owned by a random user. Sane people don't expect crap like this to happen, for a very good reason.
AppArmor's unique change_hat confinement can block this
change_hat is not a feature... it's a horrible bug, real security solutions like SELinux have explicitly rejected bugs like this. Please don't pretend you've done something useful.
Any network client (Firefox, Thunderbird, Gaim/Pidgin, etc.) can be compromised by remote vulnerabilities and malicious content, giving the attacker total control of your user account. AppArmor confinement of your clients makes it safe to e.g. IRC to strangers.
Do you plan on shipping Firefox with a useful profile that will stop it doing this? This is on the roadmap for SELinux, and they can do useful confinment because they aren't limited to pathnames... and guessing and hoping based on trial runs. Also have you at least worked out why AppArmor thinks thunderbird needs setuid()?
I specifically mentioned RAID1+0... Ie. 8 disks, as 4 RAID1 sets combined into a RAID0 set. This gives the same storage as 5 disks as RAID5 but better performance and you need at least two disks to fail (and likely more would need to fail, best case requires 5 disks to fail).
If you wanted to leave RAID5 in, you could do RAID1+5 which requires 10 (double) disks to get the same storage but this requires at least 4 disks to fail before you might have a problem (best case requires 7 disks to fail).
Yes, in theory, you can go with RAID5 DP over 6 disks and get the same minimum protection of RAID1+0... but performance is much worse, and if any 2 disks fail everything is gone.
The usual way to go, if RAID5 is not enough, is to combine RAID levels. One "common" one being a group of RAID1 sets which are then RAID0'd together.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
Cheap branches? Subversion has cheap branches.
Better merging? This is a result of algorithms has nothing to do with whether the system is centralized or not.
If you're on a fast net with the server you can commit as often as you like. If you can branch/merge easily it's no problem.
If you want to cite advantages for decentralized version control it might be more like:
If you have to talk to a server over slow links, decentralized is much better
As Linus said in the talk, when people say they want "cheap branching" what they really want is also "cheap merging"... SVN has the former, which is worthless on it's own. If "fixing merging" in SVN was "just a matter of fixing the algorithms" why have the SVN/CVS developers failed to do it in the last 10/5 years? The reason is that how difficult the algorithms are depend on your storage model... and the CVS/SVN storage models are broken. Also, even at GigE speeds, talking over the network is significantly slower than talking to the HDD.
Also I'd like to live in your world where you always have fiber type speeds to your central repo.... and neither the network or the machine itself ever goes down. Don't forget about when I've just taken a plane flight to X, which is 1,000s of miles from where I normal am. But however much I'd like to, I don't live in that world... and I find it hard to believe that I'll live in that world in my lifetime.
I've also had to "contribute" to more than one "project"[1] using a CVS/SVN repo. where I didn't have commit privs.... I find it hard to believe anyone who has lived through this pain could argue that it's a good idea, or helps anyone. So you must also be extremely lucky in that regard. You apparently live a blessed life.
[1] Project here isn't codeword for OSS, this is exactly as painful in CVS/SVN/clearcase/perforce/etc. inside a company.
There is also a third option, "program intentionally doesn't check I/O errors, as it's just informational text... and is now broken, or contains copious except blocks in it". This is esp. important for certain types of I/O like "disk full"... because they almost never happen, are easily checked by looking at close() (Ie. The C/POSIX idiom: if (close() != -1) rename();) when you have a normal language.
Also IOError is also invisibly spewed by python if the file doesn't exist, which is often not even close to an "exceptional" event. So people often just introduce races into their python code by calling stat(), and then open if that succeeds, putting more spurious stack traces in front of the user. And if anyone wants to use open(foo, "r+") and get all their try/except blocks right... good luck to them (but they'll be alone).
James - Still waiting to experience one python app. that doesn't dump stack traces to the user at random corner cases, even the ones he's written:(.
Note that there is a HUGE difference between "moderate proficiency" and "very proficient". I figure it took me about 3,000 hours of C programming to get to the "very proficient" tier (it was also my first professional gig).
So, 40-80 hours or more is "moderately proficient" and then you go straight from that level to "very proficient" at roughly 40 times as long? IMNSHO there is a big different between someone with a couple of weeks and a couple of months experience. Also 3,000 hours is roughly 18 months, and personally I wouldn't believe someone is very proficient with only that amount of experience in C. So your definition of very proficient is probably very different to mine.
Moderate proficiency is what half the OSS C code out there is. (I'm not counting the sendmails and apaches of the OSS world either). It works, it's obvious-bug free, it's not elegant and it's probably nowhere near optimal -- and desperately needs peer review from an expert to point out where improvements can be made.
It's "obvious-bug free", hell I'm impressed if I do that in C over ten years later. Give me some more of those moderately proficient people! I'm not sure what you meant by "half the OSS code out there", I'm guessing you misspelt "half the code out there"... and just mean moderately proficient is in the middle of the pack somewhere.
C [to me] implies unistd, stdlib, stdio, strings, etc, but not xpg4, sockets, iconv, blah de blah.
I'd expect an average POSIX/C programer to at least have some understanding of sockets, and with C "strings" is pretty openended... it's also somewhat harder for me to say where moderately proficient should begin/end, as I'd be tempted to think of anyway still using pretty much any "string" functions from string.h as having moderate proficency at best (which I'm not sure is completely fair).
What kind of programming education did you have? One of the courses at my university had the explicit goal that after that course you'd be able to pick up any programing language in about two weeks.
Maybe I didn't explain well, or maybe I'm expecting too much out of the phrase "moderately proficient". But proficient is defined as: Well advanced in any branch of knowledge or skill; possessed of considerable acquirements; well-skilled; versed; adept. To assume you'll be even "moderately well-skilled" in two weeks, is to assume a lot, IMNSHO.
Let's take a real world example of python, now when I first looked at python I knew C and perl well, as well as having more than a a few hours experience with a random number of other languages, pascal, asm, lisp, miranda, prolog, whatever.
So sure, within a couple of hours I knew what the syntax for the core language was and I could "write good C in python"... but I sure wouldn't have called myself "moderately proficient" in python.
After the "virtual two weeks" I had short term memory for the parts of the std. library I'd used, understood some corner cases like "global" vars and had stopped forgetting to put "pass" in places due to the retarded whitespace syntax. But those were/are all small improvements over that initial couple of hours "looks like C without braces" knowledge.
For "moderate proficiency" it was probably months of work away, and involved understanding much more of the std. library, not just what duck typing is but how you can use it well, at least some of the performance concerns with things like growable string data, using yield / closures in the "right" places, using classes and decorators etc. etc.... just generally having a good chance of writing ok-good python in python.
I could certainly pick up Ruby, Python, Perl and Java if the mood struck my. Probably two weeks each to moderate proficiency.
You might know the syntax, and how to write hello world in much less time than that but either your definition of "moderate proficiency" is very different to mine or I just don't believe you. Think of how you would react if some Perl/Python programer said "Sure, I don't know LISP or C... but I could probably get to moderate proficiency in two weeks".
Slashdot Mirror
Ermm ... how much do you think a decent developer costs? Even if you payed $500,000 for the engine, if you got two core engine developers for two years that could easily be half of what you payed (note, I'm talking about what it costs Epic, not what the developer will get as net pay).
So a series that only included bindings to a single widget set should have in the implicit expansion a completely different widget set? The "etc." stood for the perl elisp etc. (hope you can see where this is going now) bindings that I didn't list.
Let's see, GTK is the default in Fedora and Ubuntu. Mono/C# and Java basically only have GTK bindings. For a commercial entity (which you said you were) you have to pay for Qt and don't have to pay for GTK ... I'm kind of assuming, again, but this doesn't seem that hard of a question to me.
Sure it can, sure. Now close your eyes for a bit, you might not want to see this next bit.
I'm sorry, what? This isn't 1995 anymore where Motif and libXaw were the main GUI toolkits. gtk+, pygtk, gtk#, SWT, etc. are shipped in every distribution containing all the common widgets and are free to use. Maybe you mean your visual-studio developers can't use anything else? Well have fun in hell with that snowball waiting for MS to port the apps. you've locked yourself into.
And as counter argument I give you God of War 1 and 2, both of which have naked breasts at multiple points. And both have "sex games" to earn experience.
Let's face it video game ratings are just done using a bag of popcorn a 10 sided die factoring in the phase of the moon, just Film ratings.
Well I had a similar problem, although the other events were ok so I could finish the level. The problem for me was that the intuitive interface was for you to "push" where the door was. What you actually needed to do was "shake" where the door would be, if closed. After that revelation (which took _many_ tries, and random internet searches) it was about par.
Yes, but AIUI there's no legal way, in the US, to move something from being in the copyright bucket to being in the "public domain" bucket ... without waiting for death + 30^W 50 ^W 70 years. Just saying "this code is public domain" leaves you open to warranty claims and leaves your users open to being sued by your estate for copyright infringement. Just BSD+MIT+whatever multi-license it, it does the same thing but protects everyone involved.
It's not quite so simple, deducting interest from your mortgage only reduces the rate by roughly 1% (given a sane rate). Also it's general financial advise to diversify, so even though it might not be the "theoretically best" option putting a small percentage of your investments into your low interest debt. isn't a bad thing.
Actually that's just wrong. Red Hat doesn't really pay for them, the HW vendors like HP and IBM do ... so Trusted*BSD should easily be able to get that certification, if people wanted to buy systems with it.
But in my opinion the real major difference is that Fedora is a usable general purpose OS with MAC capabilities, this is like if FreeBSD shipped all of the code for MAC and TrustedBSD just shipped a policy file to enable it. In fact it's better than that, because Fedora ships with a "simpler policy" using those same code paths that is helpful and usable by normal people (incl. things like generic rsync/cp/mv/tar/etc. support). This means that it's all much better tested than other MAC implementations, IMO. This was/is a huge effort on Red Hat's part, and is currently unequaled on non-Linux platforms.
Being optimistic I'm hoping what he really meant was something like: "Linux and win32 are very different, you can't instantly program for one just because you've done so on the other. To add even more fun to the mix all your favourite tools won't be there if you go from win32 to Linux."
Although this works just as badly the other way around, all of the Linux software I've seen "ported" to win32 has just as many problems because win32 is not even close to Linux.
But you're probably right, it was probably just macho my X is better bullshit.
To be fair this is almost always not directly the fault of SELinux, the Linux kernel has a few newer "security" options like "allow apps. to mmap() onto page 0" which they default to "off" for compatibility but SELinux defaults to "on" so that it can deny them per. process (SELinux, like most security software, doesn't like to grant privilages but just remove them).
I appreciate that it doesn't help you when you are trying to debug the problem though.
No it isn't a security problem because it isn't said/assumed/documented to be secure when we know it isn't. Yes, SELinux could have setcon() used to go from httpd to httpd_mod_perl and back again ... but it would be smoke and mirrors, and would just confuse people instead of working on a real solution to the problem. change_hat() is a bug because you are advertising it to be secure which it clearly isn't. As with a lot of AppArmor it would be much more palatable if you advertised what it did, and not what you want it to do (of course then people aren't going to want to use it to do things it can't ... but that's life).
I'm not sure where you get this from, maybe you should try using/understanding SELinux? Normal users regularly change permissions (via. the change context commands: chcon or nautilus) so that httpd/samba/ftp can/cannot read files. Much as they change permissions (via. the unix mode commands: chmod and nautilus) to make things readable/executable etc.
Again, you speak as though that's a good thing ... as though that maps to any kind of normal behaviour that any sane person would expect.
No the difference is that you, and AppArmor supporters in general, keep saying the GUI learning tools is "the one true way" often at least heavily implying you don't need to do anything else if not outright saying SELinux sucks because you can't just run one tool and be done. So, yeh, technically with AppArmor you can "have it be secure, just write/review it all by hand" in the real world that isn't happening with AppArmor profiles.
The SELinux people keep trying to inform everyone that no matter what you do you need to "write" most of the policy seperately from the application. Sure, you can have GUI tools create most/all of it for you (Eg. select a drop down for: I'd like a normal networking daemon that binds to port X, and logs data in directory Y). You can even do "fixups", where you react to a couple of messages like "X permission is disallowed for Y" by a command that changes the policies. This way you find out thunderbird wants setuid() not when someone sees that permission granted in it's profile and thinks "wtf, does someone own my machine", but when someone sees that permission denied and thinks "wtf, but who cares it's denied".
No, we just have to contend with AppArmor advocates on every news site whenever SELinux is mentioned ... often bending the truth more than a little. Also are you seriously trying to suggest that the only kernel developers complaining about your design are SELinux advocates? Mind you I guess Richard Gooch started to get a little paranoid too, at the end -- I only hope AppArmor doesn't cause as much pain before it dies.
Not at all, setcon() has been around for a long time it's just not advertised/used for this case explicitly because it's not secure. The fact you added a stupid cookie value doesn't make change_hat secure, and the fact you are advocating it as secure means that it's insecurity is a bug.
For instance you keep advocating it for "mod_perl security" ... except what you mean is that "if you are really lucky mod_perl will be more confined than the rest of apache-httpd, but then again maybe not", and what a lot of people want from mod_perl security is for two different users of apache-httpd using perl code to be "secure/confined from each other, and from the web server itself" ... change_hat provides neither of these.
But, as I said, do they those profiles do anything useful. With SELinux you can have firefox allowed to write files everywhere you can, but they'll be labeled firefox_net_untrusted_t or whatever. You won't be allowed to overwrite files that haven't been previously downloaded from firefox, you can disable exec privilages on downloaded executables etc. etc. AIUI AppArmor can do none of this "higher level, useful, things" all it can do is blanket "firefox can't write files in ~/home, etc.".
Of course it makes sense, as long as you continually advocate that the "best" way to generate policies is to run applications and allow them to do everything that they are doing ... that isn't confinment. SELinux also generates WtF? moments, it just also protects you while it is telling you your apps. are on crack (or using generic code which needs privs they don't, like password checking which opens /etc/shadow directly but falls back to using a secure helper -- but lucky AppArmor users just get all their passwords stolen instead).
But it's still not upstream, and that's not because the developers have some political/technical reason ... just that it's so horrible the majority of the upstream developers don't want it. SELinux has been in the upstream kernel for years, and so is distributed by basically everybody now. Is supported by at least 4 different distributions.
So, yeh, well done ... you don't need to patch anymore, you just need to load a module that has to be compatible with your kernel and is likely to always be distributed seperately and thus. by a very small number of distributors. Sounds great!
This is a mis-characterization of the AppArmor model. AppArmor confines the processes to the filepaths you tell it to ... this is like if some random program created a link to /etc/passwd (say, to do some weird locking) the new filename would automatically get permissions of 666 or owned by a random user. Sane people don't expect crap like this to happen, for a very good reason.
change_hat is not a feature ... it's a horrible bug, real security solutions like SELinux have explicitly rejected bugs like this. Please don't pretend you've done something useful.
Do you plan on shipping Firefox with a useful profile that will stop it doing this? This is on the roadmap for SELinux, and they can do useful confinment because they aren't limited to pathnames ... and guessing and hoping based on trial runs. Also have you at least worked out why AppArmor thinks thunderbird needs setuid()?
I specifically mentioned RAID1+0 ... Ie. 8 disks, as 4 RAID1 sets combined into a RAID0 set. This gives the same storage as 5 disks as RAID5 but better performance and you need at least two disks to fail (and likely more would need to fail, best case requires 5 disks to fail).
If you wanted to leave RAID5 in, you could do RAID1+5 which requires 10 (double) disks to get the same storage but this requires at least 4 disks to fail before you might have a problem (best case requires 7 disks to fail).
Yes, in theory, you can go with RAID5 DP over 6 disks and get the same minimum protection of RAID1+0 ... but performance is much worse, and if any 2 disks fail everything is gone.
Here's what I have in my ~/.vimrc
The "syntax off" bit will stop it doing syntax highlighting, but set bg=dark fixed the colours for me so I didn't need that anymore.
The usual way to go, if RAID5 is not enough, is to combine RAID levels. One "common" one being a group of RAID1 sets which are then RAID0'd together.
As Linus said in the talk, when people say they want "cheap branching" what they really want is also "cheap merging" ... SVN has the former, which is worthless on it's own. If "fixing merging" in SVN was "just a matter of fixing the algorithms" why have the SVN/CVS developers failed to do it in the last 10/5 years? The reason is that how difficult the algorithms are depend on your storage model ... and the CVS/SVN storage models are broken. Also, even at GigE speeds, talking over the network is significantly slower than talking to the HDD.
Also I'd like to live in your world where you always have fiber type speeds to your central repo. ... and neither the network or the machine itself ever goes down. Don't forget about when I've just taken a plane flight to X, which is 1,000s of miles from where I normal am. But however much I'd like to, I don't live in that world ... and I find it hard to believe that I'll live in that world in my lifetime.
I've also had to "contribute" to more than one "project"[1] using a CVS/SVN repo. where I didn't have commit privs. ... I find it hard to believe anyone who has lived through this pain could argue that it's a good idea, or helps anyone. So you must also be extremely lucky in that regard. You apparently live a blessed life.
[1] Project here isn't codeword for OSS, this is exactly as painful in CVS/SVN/clearcase/perforce/etc. inside a company.
There is also a third option, "program intentionally doesn't check I/O errors, as it's just informational text ... and is now broken, or contains copious except blocks in it". This is esp. important for certain types of I/O like "disk full" ... because they almost never happen, are easily checked by looking at close() (Ie. The C/POSIX idiom: if (close() != -1) rename();) when you have a normal language.
Also IOError is also invisibly spewed by python if the file doesn't exist, which is often not even close to an "exceptional" event. So people often just introduce races into their python code by calling stat(), and then open if that succeeds, putting more spurious stack traces in front of the user. And if anyone wants to use open(foo, "r+") and get all their try/except blocks right ... good luck to them (but they'll be alone).
James - Still waiting to experience one python app. that doesn't dump stack traces to the user at random corner cases, even the ones he's written :(.
So, 40-80 hours or more is "moderately proficient" and then you go straight from that level to "very proficient" at roughly 40 times as long? IMNSHO there is a big different between someone with a couple of weeks and a couple of months experience. Also 3,000 hours is roughly 18 months, and personally I wouldn't believe someone is very proficient with only that amount of experience in C. So your definition of very proficient is probably very different to mine.
It's "obvious-bug free", hell I'm impressed if I do that in C over ten years later. Give me some more of those moderately proficient people! I'm not sure what you meant by "half the OSS code out there", I'm guessing you misspelt "half the code out there" ... and just mean moderately proficient is in the middle of the pack somewhere.
I'd expect an average POSIX/C programer to at least have some understanding of sockets, and with C "strings" is pretty openended ... it's also somewhat harder for me to say where moderately proficient should begin/end, as I'd be tempted to think of anyway still using pretty much any "string" functions from string.h as having moderate proficency at best (which I'm not sure is completely fair).
Maybe I didn't explain well, or maybe I'm expecting too much out of the phrase "moderately proficient". But proficient is defined as: Well advanced in any branch of knowledge or skill; possessed of considerable acquirements; well-skilled; versed; adept. To assume you'll be even "moderately well-skilled" in two weeks, is to assume a lot, IMNSHO.
Let's take a real world example of python, now when I first looked at python I knew C and perl well, as well as having more than a a few hours experience with a random number of other languages, pascal, asm, lisp, miranda, prolog, whatever.
So sure, within a couple of hours I knew what the syntax for the core language was and I could "write good C in python" ... but I sure wouldn't have called myself "moderately proficient" in python.
After the "virtual two weeks" I had short term memory for the parts of the std. library I'd used, understood some corner cases like "global" vars and had stopped forgetting to put "pass" in places due to the retarded whitespace syntax. But those were/are all small improvements over that initial couple of hours "looks like C without braces" knowledge.
For "moderate proficiency" it was probably months of work away, and involved understanding much more of the std. library, not just what duck typing is but how you can use it well, at least some of the performance concerns with things like growable string data, using yield / closures in the "right" places, using classes and decorators etc. etc. ... just generally having a good chance of writing ok-good python in python.
You might know the syntax, and how to write hello world in much less time than that but either your definition of "moderate proficiency" is very different to mine or I just don't believe you. Think of how you would react if some Perl/Python programer said "Sure, I don't know LISP or C ... but I could probably get to moderate proficiency in two weeks".