[gentoo-dev] Re: GCC 4.7 unmasking
Rich Freeman posted on Mon, 25 Feb 2013 17:54:01 -0500 as excerpted: > I didn't not read that email SIGFPE. Talk about -ffastma^h^hfinger errors... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 5:02 PM, Ryan Hill wrote: > On Sun, 24 Feb 2013 23:03:01 -0600 > Ryan Hill wrote: > >> I'm going to be unmasking 4.7.2 later this week. There are still 47 open >> bugs >> blocking the 4.7 tracker, so if any are yours now would be a good time >> to take a look at them. >> >> https://bugs.gentoo.org/390247 > > Forgot to say, now would also be a great time for those crazy arch people to > attempt a build on their crazy arches. :p mips looks good! :)
[gentoo-dev] Re: GCC 4.7 unmasking
On Sun, 24 Feb 2013 23:03:01 -0600 Ryan Hill wrote: > I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs > blocking the 4.7 tracker, so if any are yours now would be a good time > to take a look at them. > > https://bugs.gentoo.org/390247 Forgot to say, now would also be a great time for those crazy arch people to attempt a build on their crazy arches. :p -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
[gentoo-dev] Re: GCC 4.7 unmasking
On Mon, 25 Feb 2013 21:58:08 +0100 Piotr Szymaniak wrote: > On Sun, Feb 24, 2013 at 11:03:01PM -0600, Ryan Hill wrote: > > I'm going to be unmasking 4.7.2 later this week. There are still 47 open > > bugs blocking the 4.7 tracker, so if any are yours now would be a good time > > to take a look at them. > > > > https://bugs.gentoo.org/390247 > > There's an ugly bug [1] with -ffast-math discovered by mednafen > developer(s?). Don't know if this is revelant for unmasking and if > -ffast-math is "supported". > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125 Thanks for the heads up. I'll add this to our patchset. I'm not sure if it warrants an -r2 or not. -ffast-math as a general flag is not supported. Some packages are designed to work with it and their build systems add it. That's fine and we want them to keep working. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On 02/25/2013 12:48 PM, Michael Mol wrote: > On Mon, Feb 25, 2013 at 2:21 AM, Matthew Thode > wrote: >> On 02/24/13 20:25, Michael Mol wrote: >>> (I really don't have time to actively participate on this list right >>> now, but I believe that if I bring it up on b.g.o, I'll be directed >>> here, so...) >>> >>> So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to >>> enable kerberos system-wide on my server. >>> >>> No joy, as net-fs/nfs-utils has an explicit dependency on >>> app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on >>> app-crypt/heimdal (for reasons noted in bug 195703, comment 25). >>> >>> Questions: >>> >>> 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 >>> and kerberos demands that things with explicit dependencies on mit-krb5 >>> either be fixed or not used at all. >>> >>> I'm the first activity on bug 231936 in two years...could someone please >>> look into that one? >>> >>> 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them >>> through a virtual? My suspicion is "no", but I don't know enough about >>> kerberos to say whether or not it would work, even as a hack. >>> >>> I'm sure explicit dependencies on mit-krb5 and heimdal will continue to >>> crop up, so (and forgive the nausea this might cause) it might help to >>> slot mit and heimdal, and have virtual/krb5 depend on the presence of at >>> least one. >>> >> so, read the thread so far, and I think you are over-complicating things >> with slotting. I use kerberos at home (more or less just to learn it, >> worksforme, etc). I chose MIT. From what I understand MIT and heimdal >> are mutually exclusive (can not operate with eachother) and that heimdal >> is what windows uses. > > I think they're effectively the same on the wire, but I'm not sure. > I'm studying the issue. For the record: On my system, the only two changes I had to make to enable kerberos (largely) system-wide were: 1) mask net-fs/nfs-utils (it was only being brought in by the kerberos flag, anyway) 2) mask dev-libs/openssl[kerberos]. See https://bugs.gentoo.org/show_bug.cgi?id=459220 Both of those had explicit dependencies on app-crypt/mit-krb5. After that, everything built fine for app-crypt/heimdal. (No idea how well it works; I've still got a ways to go to prove/disprove any of that.) My purpose in originating this thread isn't (and hasn't been) all about getting AD operating correctly and pervasively. My purpose is in getting the package dependencies for kerberos sanified and cleaned up. If that means there are upstream issues, I can prod them, too, I suppose. (I do still wonder what all breaks if assumption is "allow mit-krb5 to be installed, rather than heimdal".) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 5:34 PM, Diego Elio Pettenò wrote: > No, an example of _how building a whole package with -ffast-math_ was > brought up, and you turned it into "something that it should apply to" > (which is false, and stupid to say). Perhaps this is part of the issue then. I didn't not read that email and get the impression that the whole package was being built against that flag. If it ever worked I'd be quite impressed (and it would likely be because the build system ignored it most of the time anyway). If that really was the example, then I can understand why my referencing it suggested that I supported this kind of use of the flag. > Software does not work like a single equation. Ever heard of fuzzing? > You know why it works? Because a single different bit can have cascade > effects. Hadn't really thought of it that way, but it makes sense. Propagation of error applies to random error when applied to integrable functions. That breaks down as soon as you stick an if() in your code. But hey, fractals are pretty... Rich
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 5:30 PM, Luca Barbato wrote: > On 25/02/13 23:21, Rich Freeman wrote: >> My point was just that: >> 1. No, the fact that entire packages fail to build/operate using >> -ffast-math is not a valid bug. > > From your email the message was the opposite, maybe a not got lost? I think that I must be cursed with some kind of cloud of misunderstanding when I write or something. This is what I'm saying: If you run CFLAGS="-ffast-math" emerge then you get to keep the pieces. If you run emerge foo, and the upstream build system happens to use -ffast-math on a single module and it has been working for 10 years and GCC 4.7 breaks it, then maybe there is something to it. Certainly I support that this is something that the gcc team and the package maintainer should work out - just because upstream does it doesn't mean that it is right. > That means that if the upstream cflags do not work (anymore?) with > certain compilers we should notify them. Seems sensible to do. I don't think we're really disagreeing here... Rich
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/2013 23:21, Rich Freeman wrote: > On Mon, Feb 25, 2013 at 5:11 PM, Diego Elio Pettenò > wrote: >> Of course dealing with flags _per functions_ is not possible, as flags >> apply at the very least to a translation unit... > > A translation unit can contain a single function, or a bunch of > functions that you want to apply the flag to. Which is a different story altogether. By the way just so you know, as you seem to talk a lot about things you understand only partially, if you want performance so badly you want to use -ffast-math, you're not going to split translation units so much. > Maybe it wasn't a great example - I wasn't the one who first brought > it up in the thread. No, an example of _how building a whole package with -ffast-math_ was brought up, and you turned it into "something that it should apply to" (which is false, and stupid to say). Note also how you can't defend your original statement, so I maintain my point: you're speaking of things you don't know. > If you add a randomly distributed 1% error to hundreds of small > calculations you end up with a 1% error in the result, roughly > speaking. The exact impact can in fact be calculated using > propagation of error. Of course, if -ffast-math introduces a > non-uniform bias and the calculations are sensitive to that then that > could carry things further off. On the distribution of errors introduced by -ffast-math I have no data. On the other hand, I know that if you start changing 1% of the calculation in a single piece of software, what you end up with is rarely "within 1%" of the intended result. Software does not work like a single equation. Ever heard of fuzzing? You know why it works? Because a single different bit can have cascade effects. > 2. If individual packages DO carefully use -ffast-math and that > breaks, it might be a valid bug, and may or may not be a blocker > depending on real-world impact. That doesn't mean users sticking it > in their CFLAGS - it means the ebuild or upstream build system > carefully applied the flag appropriately. This is arguable — I'm not going to dig down how many packages I found with -O3 (or even worse -O9), just for the sake of being "faster" and sometimes going slower than if built with -O2 (loops unrolling and inlining are not always a good idea). But, as you correctly say this time, right now we only have one _valid_ report: mednafen — which I'm surprised uses -ffast-math (given it's an emulator). So the question is whether that's a showstopper for them or not — and how serious is the performance difference between the two. Anything else, is noise. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/13 23:21, Rich Freeman wrote: > My point was just that: > 1. No, the fact that entire packages fail to build/operate using > -ffast-math is not a valid bug. >From your email the message was the opposite, maybe a not got lost? > 2. If individual packages DO carefully use -ffast-math and that > breaks, it might be a valid bug, and may or may not be a blocker > depending on real-world impact. That doesn't mean users sticking it > in their CFLAGS - it means the ebuild or upstream build system > carefully applied the flag appropriately. That means that if the upstream cflags do not work (anymore?) with certain compilers we should notify them. Seems sensible to do. lu
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/13 22:32, Rich Freeman wrote: > On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman wrote: >> Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should >> be on their own, thus I drop -ffast-math because it breaks my browser; >> but that doesn't mean that those ricer flags should stop stabilization. > > If we're talking about for general use in CFLAGs clearly -ffast-math > isn't something that even could be supported if we wanted to. The > flag is just not intended for general use. And if you stop here everything would be agreeable. > That isn't the same as saying that we can just break it in cases where > it actually is appropriate. Calculating scroll bar movement is > exactly the sort of thing that this flag was actually designed for - > you don't care if it is off by 1/100th of a pixel. Please check your facts. using -ffast-math could do anything from nothing to cause severe security issues. > But, the way to track that sort of a thing is to log those as bugs > against appropriate use within individual apps and make them blockers. No. > I'd consider things like this valid bugs - but whether they hold > things up should depend on real-world impact. I'm not sure how bad > the impact on chromium actually is. Absolutely not. Some code is _designed_ to work w/out caring about ieee corner cases and some is _designed_ to work leveraging them. NOT bug. To reinstate: if you use -ffast-math or other known-to-alter-the-standard-behaviour or, even worst, experimental flags you are on your own. lu
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 5:11 PM, Diego Elio Pettenò wrote: > Of course dealing with flags _per functions_ is not possible, as flags > apply at the very least to a translation unit... A translation unit can contain a single function, or a bunch of functions that you want to apply the flag to. > >> If you're just using it to calculate how many pixels down it is, it >> certainly shouldn't be that inaccurate. > > But you're not just calculating how many pixels down to draw it... > you're calculating a bunch of parameters, including shades, shadows, > sub-pixel positioning, Maybe it wasn't a great example - I wasn't the one who first brought it up in the thread. However, if the optimization were appropriate to apply to some things and not to others, then you'd only apply it to those things. > But if you add 1% error to hundreds of small calculations ... well, you > should get the point, don't you? If you add a randomly distributed 1% error to hundreds of small calculations you end up with a 1% error in the result, roughly speaking. The exact impact can in fact be calculated using propagation of error. Of course, if -ffast-math introduces a non-uniform bias and the calculations are sensitive to that then that could carry things further off. > > There are decent use cases for -ffast-math... none of which involve a > desktop system, in my opinion. Likely not. In which case, we won't have any blockers reported, will we? My point was just that: 1. No, the fact that entire packages fail to build/operate using -ffast-math is not a valid bug. 2. If individual packages DO carefully use -ffast-math and that breaks, it might be a valid bug, and may or may not be a blocker depending on real-world impact. That doesn't mean users sticking it in their CFLAGS - it means the ebuild or upstream build system carefully applied the flag appropriately. Whether any instances of #2 exist, I cannot say. Rich
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/2013 22:57, Rich Freeman wrote: > A sword that cuts two ways - judging understanding by an email is a > dubious proposition, otherwise we wouldn't need job interviews. :) > It is just as likely that we're simply miscommunicating. Did you not just say there: "Calculating scroll bar movement is exactly the sort of thing that this flag was actually designed for - you don't care if it is off by 1/100th of a pixel." or am I mistaken? If I'm not mistaken, that phrase is really not understanding it. The calculation that goes in painting on screen a scrollbar are hardly something you expect -ffast-math to be designed for. Can you defend your statement in any way? > Define what you mean by "building *by itself*" - I don't want to > assume I understand what you're getting at here. I certainly wasn't > suggesting that you could be able to run CFLAGS="-O2 -ffast-math" > emerge chromium and get anything usable. Which is exactly what Tom complained about. > -ffast-math is a flag that > should be applied to specific functions or even parts of functions > where there is an understood performance vs accuracy tradeoff. Of course dealing with flags _per functions_ is not possible, as flags apply at the very least to a translation unit... > If you're just using it to calculate how many pixels down it is, it > certainly shouldn't be that inaccurate. But you're not just calculating how many pixels down to draw it... you're calculating a bunch of parameters, including shades, shadows, sub-pixel positioning, > If you're using it to do > pointer arithmetic or something then you're just going to get > segfaults. Uh.. no. Pointer arithmetic is, by and of itself, integer arithmetic. That's not going to be influenced by -ffast-math. Vastly, -ffast-math deals with floating-point arithmetic, which can be sped up significantly ignoring some of the rules imposed by floating-point arithmetic by IEEE/ISO standards. Breaking which, though, can lead to seriously messed up results. > There are arithmetic functions in computing that are > discrete/functional in nature, and there are those which relate more > to real-world measurements. Adding a 0.001% error to a hash > calculation breaks a hash. Adding 0.001% error to a scientific > calculation where all the components have 1% measurement error is > insignificant. But if you add 1% error to hundreds of small calculations ... well, you should get the point, don't you? There are decent use cases for -ffast-math... none of which involve a desktop system, in my opinion. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 4:37 PM, Diego Elio Pettenò wrote: > On 25/02/2013 22:32, Rich Freeman wrote: >> That isn't the same as saying that we can just break it in cases where >> it actually is appropriate. Calculating scroll bar movement is >> exactly the sort of thing that this flag was actually designed for - >> you don't care if it is off by 1/100th of a pixel. > > Rich.. please... don't try to talk about things you don't understand. > A sword that cuts two ways - judging understanding by an email is a dubious proposition, otherwise we wouldn't need job interviews. :) It is just as likely that we're simply miscommunicating. > If Chromium is not building *by itself* on -ffast-math, we should *not* > support building it with it. Full stop. Define what you mean by "building *by itself*" - I don't want to assume I understand what you're getting at here. I certainly wasn't suggesting that you could be able to run CFLAGS="-O2 -ffast-math" emerge chromium and get anything usable. -ffast-math is a flag that should be applied to specific functions or even parts of functions where there is an understood performance vs accuracy tradeoff. > It's not that adding -ffast-math loses the 1/100th precision on a scroll > bar pixel: it has a truckload of changes to the whole mathematics in the > code, which _among other things_ will break that scrollbar, because the > calculation used to display it add up to a huge difference. If you're just using it to calculate how many pixels down it is, it certainly shouldn't be that inaccurate. If you're using it to do pointer arithmetic or something then you're just going to get segfaults. There are arithmetic functions in computing that are discrete/functional in nature, and there are those which relate more to real-world measurements. Adding a 0.001% error to a hash calculation breaks a hash. Adding 0.001% error to a scientific calculation where all the components have 1% measurement error is insignificant. > I would be wondering about it if it broke stuff that > already is designed to rely on it, but even in that case, it's hard to > actually say that it "broke", it's just "different". This is the case I'm concerned with only. Agree somewhat on "broken" being a loose term when the flag is intended to yield inaccurate results. However, it probably is not intended to yield grossly-inaccurate results. Then again, the bug cited things like 5 vs 7 and those are equivalent within an order of magnitude. Rich
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/2013 22:32, Rich Freeman wrote: > That isn't the same as saying that we can just break it in cases where > it actually is appropriate. Calculating scroll bar movement is > exactly the sort of thing that this flag was actually designed for - > you don't care if it is off by 1/100th of a pixel. Rich.. please... don't try to talk about things you don't understand. If Chromium is not building *by itself* on -ffast-math, we should *not* support building it with it. Full stop. It's not that adding -ffast-math loses the 1/100th precision on a scroll bar pixel: it has a truckload of changes to the whole mathematics in the code, which _among other things_ will break that scrollbar, because the calculation used to display it add up to a huge difference. So no, I don't care if -ffast-math "breaks" in the sense that stuff that does not build with -ffast-math to begin with work even less with the new version — I would be wondering about it if it broke stuff that already is designed to rely on it, but even in that case, it's hard to actually say that it "broke", it's just "different". -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: kerberos, virtuals, rattling cages
On 02/25/2013 06:03 AM, Duncan wrote: > Eray Aslan posted on Mon, 25 Feb 2013 10:02:49 +0200 as excerpted: > I don't think samba will support MIT, since it's kinda windows focused. >> >> Ugh, no. MIT is not windows focused > > ... But samba is... Actually, no. That's why I've been so excited about Samba 4, and why I'm setting it up at home. AD is actually a very powerful network administration tool, and it's not necessary to think of it as a "Windows thing". Think of it more like a sane replacement of NIS, tying in NTP and DNS management as well. > > > As far as the thread in general goes, the question arises, if you're > running both samba and nfs, why? They're both network-based-filesystems > that in theory at least should have reasonably similar functionality, so > an admittedly not particularly clueful reaction is "if it hurts when you > do that, stop doing it". It's incredibly rare to see a uniform enterprise network. Every one I've witnessed is heterogenous. The reasons usually come in a mix of these flavors: 1) There's no policy for homogeneity. 2) Department A does it one way, department B does it another way, and both departments are largely autonomous. 3) There needs to be integration between system A and system B, and neither of those systems can reasonably be expected to change from their current state. 4) Someone mandated a "solution" that only supports X and Y, and it's not worth the resources and risk of revamping the entire rest of the network to meet that spec natively. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman wrote: > Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should > be on their own, thus I drop -ffast-math because it breaks my browser; > but that doesn't mean that those ricer flags should stop stabilization. If we're talking about for general use in CFLAGs clearly -ffast-math isn't something that even could be supported if we wanted to. The flag is just not intended for general use. That isn't the same as saying that we can just break it in cases where it actually is appropriate. Calculating scroll bar movement is exactly the sort of thing that this flag was actually designed for - you don't care if it is off by 1/100th of a pixel. But, the way to track that sort of a thing is to log those as bugs against appropriate use within individual apps and make them blockers. I'd consider things like this valid bugs - but whether they hold things up should depend on real-world impact. I'm not sure how bad the impact on chromium actually is. Rich
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, 25 Feb 2013 21:58:08 +0100 Piotr Szymaniak wrote: > On Sun, Feb 24, 2013 at 11:03:01PM -0600, Ryan Hill wrote: > > I'm going to be unmasking 4.7.2 later this week. There are still > > 47 open bugs blocking the 4.7 tracker, so if any are yours now > > would be a good time to take a look at them. > > > > https://bugs.gentoo.org/390247 > > There's an ugly bug [1] with -ffast-math discovered by mednafen > developer(s?). Don't know if this is revelant for unmasking and if > -ffast-math is "supported". > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125 > > > Piotr Szymaniak. -ffast-math on certain libs cause chrom(ium|e) to fail when scrolling on certain sites (eg. Google News) and pages (Extensions and Settings), this happened to me on GCC 4.7.2. Whether or not this is intended to break due to the sacrifices this flag makes is questionable... Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should be on their own, thus I drop -ffast-math because it breaks my browser; but that doesn't mean that those ricer flags should stop stabilization. With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] GCC 4.7 unmasking
On Sun, Feb 24, 2013 at 11:03:01PM -0600, Ryan Hill wrote: > I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs > blocking the 4.7 tracker, so if any are yours now would be a good time > to take a look at them. > > https://bugs.gentoo.org/390247 There's an ugly bug [1] with -ffast-math discovered by mednafen developer(s?). Don't know if this is revelant for unmasking and if -ffast-math is "supported". [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125 Piotr Szymaniak. -- Mysle, ze gdyby diabel nie istnial i mialby go stworzyc czlowiek, to stworzylby go na swoj obraz i podobienstwo. -- Fiodor Dostojewski signature.asc Description: Digital signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Mon, Feb 25, 2013 at 2:21 AM, Matthew Thode wrote: > On 02/24/13 20:25, Michael Mol wrote: >> (I really don't have time to actively participate on this list right >> now, but I believe that if I bring it up on b.g.o, I'll be directed >> here, so...) >> >> So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to >> enable kerberos system-wide on my server. >> >> No joy, as net-fs/nfs-utils has an explicit dependency on >> app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on >> app-crypt/heimdal (for reasons noted in bug 195703, comment 25). >> >> Questions: >> >> 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 >> and kerberos demands that things with explicit dependencies on mit-krb5 >> either be fixed or not used at all. >> >> I'm the first activity on bug 231936 in two years...could someone please >> look into that one? >> >> 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them >> through a virtual? My suspicion is "no", but I don't know enough about >> kerberos to say whether or not it would work, even as a hack. >> >> I'm sure explicit dependencies on mit-krb5 and heimdal will continue to >> crop up, so (and forgive the nausea this might cause) it might help to >> slot mit and heimdal, and have virtual/krb5 depend on the presence of at >> least one. >> > so, read the thread so far, and I think you are over-complicating things > with slotting. I use kerberos at home (more or less just to learn it, > worksforme, etc). I chose MIT. From what I understand MIT and heimdal > are mutually exclusive (can not operate with eachother) and that heimdal > is what windows uses. I think they're effectively the same on the wire, but I'm not sure. I'm studying the issue. > > What this seems to be is a simple case of blockers. So, the quesiton > is, are you going to be using kerberos in nfs? if not, masking the flag > may be what works for you (in the short term at least). Longer term it > sounds like maybe seperate use flags are in order (or something, dunno). It's the longer-term thing is what I'm interested in solving...and smoothness of kerberos in Gentoo in general. SSO for a family network would be very, very nice. > > I don't think samba will support MIT, since it's kinda windows focused. > > On another note, I can't find bug 231936. Typo. Or dyslexia. Who know... https://bugs.gentoo.org/show_bug.cgi?id=231396 -- :wq
Re: [gentoo-dev] Re: kerberos, virtuals, rattling cages
On Mon, Feb 25, 2013 at 9:33 AM, Alan McKinnon wrote: > Linux client invariably whinge at length about how the performance of > samba sucks. I suspect there is more at issue than just performance. I run both samba and nfs (though without kerberos), and have the windows issues you mentioned, and I doubt that you can use samba as a root filesystem (that sounds painful at the very least), which is one of the things I use it for. NFS is just a lot cleaner for linux clients. Rich
Re: [gentoo-dev] Re: kerberos, virtuals, rattling cages
On 25/02/2013 13:03, Duncan wrote: > Eray Aslan posted on Mon, 25 Feb 2013 10:02:49 +0200 as excerpted: > I don't think samba will support MIT, since it's kinda windows focused. >> >> Ugh, no. MIT is not windows focused > > ... But samba is... > > > As far as the thread in general goes, the question arises, if you're > running both samba and nfs, why? They're both network-based-filesystems > that in theory at least should have reasonably similar functionality, so > an admittedly not particularly clueful reaction is "if it hurts when you > do that, stop doing it". > Two words: mixed environment In corporate networks it is very common to share the same backend over both smb/cifs and nfs. Windows clients can't easily deal with anything other than cifs. Linux client invariably whinge at length about how the performance of samba sucks. Solution: run both protocols, everyone wins. It only goes south when AD/Kerberos enters the mix. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: kerberos, virtuals, rattling cages
Eray Aslan posted on Mon, 25 Feb 2013 10:02:49 +0200 as excerpted: >> > I don't think samba will support MIT, since it's kinda windows >> > focused. > > Ugh, no. MIT is not windows focused ... But samba is... As far as the thread in general goes, the question arises, if you're running both samba and nfs, why? They're both network-based-filesystems that in theory at least should have reasonably similar functionality, so an admittedly not particularly clueful reaction is "if it hurts when you do that, stop doing it". -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On Sun, Feb 24, 2013 at 11:43:06PM -0800, Alec Warner wrote: > This is incorrect, or at least, was incorrect last time I looked > (circa...uhh..2009?) > > They work 'ok' together. Heimdal clients could talk to MIT servers at > least. and vice-versa. > Of course, there were quirks, and incompatible command line > syntax, hence my fierce recommendation to 'not do that.' Yes. > > I don't think samba will support MIT, since it's kinda windows focused. Ugh, no. MIT is not windows focused (although it does ship a windows client for better integration with *nix kdcs). Apple uses heimdal in recent macos'es and employs some main developers of heimdal and samba (hence samba - heimdal tight integration). There was some work from red hat to make samba4 work with mit-krb5 but it stalled and did not go anywhere (yet?) afaik. -- Eray Aslan pgpXAuWmotvL_.pgp Description: PGP signature
