Re: can we (fully) release-goal decommissioning of trolls
On Tue, 2012-08-21 at 00:47 +0200, Josselin Mouette wrote: Thanks for this excellent example of the behavior I described. With “down to Windows level” you must think you have hit the trigger of the ultimate bazooka to shut people up, don’t you? Well Josselin,... I'm not generally against new technologies (like PolicyKit, CK, and all the uoptia stuff) but I guess no one can deny the following: - Some of these get deprecated in a yearly fashion (HAL, DeviceKit, and not apparently ConsoleKit)... which is IMHO quite bad for developers using this stuff. - Some of them have quite some severe bugs; I remember one where (was it DeviceKit or udisks?) the dm-crypt keys of encrypted volumes were exported to the user... (Of course, other software has bugs, too.) - Most of them are difficult to understand. Take PolicyKit. I'm sure you can do a lot with it, but also, that most People just don't know how. Partially that is definitely a documentation problem, partially of course also, that users tend to refuse to learn new things. And with respect to what Stefan wrote: - I think that many of these new technologies have at least a default config that is written from a desktop computers point of view. Which often means that settings are in a way, that people with strong security in mind won't like it. Even if, by default, it just allows you to connect to any network. Similar (security) problems are (possibly) brought by techniques like Avahi... I guess that what people in these kind of discussion mean sometimes when comparing the stuff to Windows/Apple. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: can we (fully) release-goal decommissioning of trolls
On Mon, 2012-08-20 at 12:38 +0200, Josselin Mouette wrote: This is untrue. Any *physically logged on* user can connect to any network. For a desktop system this is clearly a reasonable default Well the are people that may disagree here. Of course this is dependent on personal views. Anyway what _I_ meant is now described and reported now in https://bugzilla.gnome.org/show_bug.cgi?id=682406 . :) And yes, I know, it's already an issue when managed mode was enabled. This is a reasonable choice, given that most distros have very basic or nonexistent network configuration (/etc/sysconfig/network-scripts hahaha) and those who have a decent one were not designed for high level integration. Uhm... yeah well,... I personally don't think so,.. because distros (I guess including Debian), will continue to have and user their own native tools... whether they're perfect or not. (And I agree with your laughter on /etc/sysconfig/network* ;-) ) 3) ifupdown integration is really bad Which is why it is disabled by default. Not that it hurts much. People who want to continue using /e/n/i will have to enable it, or it won't work at all... or do I miss something? And IMHO it's invalid to demand that people should drop their use of a well proven system. If you want to fix this broken set of features that is not enabled by default, send patches. I'm currently not to inclined in getting into NM development... and I guess it's not forbidden to discuss / report bugs or ideas for enhancements... when one is not part of the developers, is it? ;) c) when NM is running, I cannot use ifup foo / ifdown foo / ifconfig parameters... well I can.. but then everything gets really messed up So what? What actual problem does it cause? E.g. scripts using them automatically don't work any longer. Consider something like a cron script, that needs to connect to some VPN and transmit periodically collected data. 4) upstream more or less doesn't want to support these scenarios... Of course, because *as you pointed out yourself*, the idea of parsing system configuration is stupid and leads to bugs. Yes but I haven't said, that this parsing wouldn't be needed to be replaced by directly using the native tools... Yes. This is actually what happens on usual setups (one interface, DHCP without any special options) upon NM installation. But you know, that not all debian installations need to be simple laptop installations, don't you? And even laptop installations can do more complex things (take my example from above). I think the disease mostly consists in old farts Wow,... very adult to insult people... These people are the disease. Jep... very adult... Chris. smime.p7s Description: S/MIME cryptographic signature
Re: can we (fully) release-goal decommissioning of trolls
On Wed, Aug 22, 2012 at 03:03:29PM +0200, Christoph Anton Mitterer wrote: Similar (security) problems are (possibly) brought by techniques like Avahi... There's not much revealed by it that's not visible from a port scan. (Ok, the hostname probably.) And the mDNS data stream is only accessible from the same broadcast domain while the announced port itself will be open to the public. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: can we (fully) release-goal decommissioning of trolls
Le dimanche 19 août 2012 à 19:26 +0200, Christoph Anton Mitterer a écrit : 1) In parts it has some security issues. - At least the default setting seems to be that any user can connect to any network. This is untrue. Any *physically logged on* user can connect to any network. For a desktop system this is clearly a reasonable default, and it can be modified through PolicyKit. - At least the network connections from /etc/network/interfaces are exported to the normal user, even if that user cannot read that file. This is also untrue. By default NM does not look at all at /e/n/i. 2) NM's design seems to be wrong. AFAIU (I didn't look into too much depth, though), NM is based on the design idea, that it replaces all network management and configuration from the respective distros. This is a reasonable choice, given that most distros have very basic or nonexistent network configuration (/etc/sysconfig/network-scripts hahaha) and those who have a decent one were not designed for high level integration. So when NM brings up a connection, it does not simply invoke some e.g. ifscheme wlan0-myHomeNet ifup wlan0 but directly invokes wpa_supplicant. That's IMHO quite awful, as you loose all the proper integration of ifupdown by gaining nothing. Because storing passphrases in the keyring is “nothing”. Because having per-user networking priorities is “nothing”. (The list could be very long.) Moreover it complicates the code, as now NM needs to come with its own /e/n/interfaces parsers (which will everytime the something changes there) Mostly irrelevant. They are disabled by default because doing so is broken by design. In my opinion, NM should: - export any connections from the real canonical places (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/* and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.) No. - only if a user doesn't find something there, a per user connection configuration should be set up. Only interfaces not already managed by /e/n/i are started up by NM. How is what you propose better? - I know, NM supports system wide configuration, too, but IMHO that should be dropped altogether and NM should also not try to edit the real canonical configuration. Yeah sure, let’s replace a proper and global system configuration that you can setup with the same GUI as per-user configuration with a bunch of parsers that will always fail to do one of the 200 things they have to manage. Weren’t you the one complaining about broken parsers 10 lines earlier? Haven’t people learned ANYTHING about disasters such as webmin? 3) ifupdown integration is really bad Which is why it is disabled by default. Not that it hurts much. Well this is similar to (2). a) NM (AFAIU) doesn't really use ifupdown for controlling, it merely parses /etc/network/interfaces Which is bad design, as you pointed out yourself. And which is why this feature should remain DISABLED. b) barely nothing from /etc/network/interfaces is supported, some bugs I've noticed: - the dns-* options from resolvconf don't work at all - wireless connections aren't exported if wpa-key-mgmt is not set (which there should be no need to in many cases), and for WPA-EAP it seems to generally not work. - the same is the case with many advanced options (ap_scan, etc. pp.) If you want to fix this broken set of features that is not enabled by default, send patches. c) when NM is running, I cannot use ifup foo / ifdown foo / ifconfig parameters... well I can.. but then everything gets really messed up So what? What actual problem does it cause? d) when I disable wireless in NM it really blocks it, so I can't use it with ifupdown. Now one can rfkill unblock then... but why? and even if one does...NM seems to get confused again. Same question as c). 4) upstream more or less doesn't want to support these scenarios... Of course, because *as you pointed out yourself*, the idea of parsing system configuration is stupid and leads to bugs. Already many months ago, I've opened a Debian bug, that some /e/n/i connections are simply not shown by NM. Given that this is actually an upstream issue, I've reported this (and most other problems I've mentioned before, especially the poor ifupdown integration but also the ideas about adding support for all the canonical configurations) upstream. I guess the conclusion is: this won't be implemented. It seems the desired scenario for NM is that /e/n/i is empty Yes. This is actually what happens on usual setups (one interface, DHCP without any special options) upon NM installation. and everything is handled Apple™ like: hide-everything, don't support advanced setups. Indeed it is not possible to support any combination of advanced setup with a pre-defined set of configuration options accessible from a GUI. Thank you, Captain Obvious. So,... at least I want to continue our wonderful ifupdown and also the other native tools (ppp,
Re: can we (fully) release-goal decommissioning of trolls
On Mon, Aug 20, 2012 at 12:38:07PM +0200, Josselin Mouette wrote: It seems the desired scenario for NM is that /e/n/i is empty Yes. This is actually what happens on usual setups (one interface, DHCP without any special options) upon NM installation. Well, until some weeks ago I never had a desktop system (even at work) with DHCP, simply because the Linux system are developer systems with different VLAN interfaces. At home my systems have static IPs as well. “wonderful” ifupdown… I guess some of us around here have other words to describe it. Maybe. For me NM was always a PITA, I always got better results with ifupdown. It is not perfect, certainly, but it works very well for me. 10 years ago, we had people complaining about ORBit. Then later they complained about D-Bus and pmount. Recently it was about PulseAudio. Now Well, Pulseaudio has its problems (you can ask the MythTV guys what they think of it). It never really worked for me with MythTV. And if you only have one audio device, chances are high that you don’t need it anyway. they don’t want to see their precious 30-year-old systemv and ifconfig crap replaced. Well, if it isn’t broken, don’t fix it. There seem to be enough people who don’t have any problems with your „systemv and ifconfig crap”, no matter how old. And they are not interested in getting new buggy software for the core system by force. So if you think, you need something new, fine, make it. But don’t break other people’s setup. These people are the disease. They are toxic to the community and tend Why, thank you. I think that these people are a disease who are always trying to drag down Linux to Windows level and are forcing their software crap on others, because they think it is so good that every one has to use it. And I would wish those people would go away to Windows. There they can play with shiny new software which doesn’t really work. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: can we (fully) release-goal decommissioning of trolls
Le lundi 20 août 2012 à 21:35 +0200, Stephan Seitz a écrit : These people are the disease. They are toxic to the community and tend Why, thank you. I think that these people are a disease who are always trying to drag down Linux to Windows level Thanks for this excellent example of the behavior I described. With “down to Windows level” you must think you have hit the trigger of the ultimate bazooka to shut people up, don’t you? We’re no longer in 1995. For some pieces of the system, “down to Windows level” would be quite an improvement. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345502867.5401.38.camel@tomoyo
Re: can we (fully) release-goal decommissioning of trolls
On 08/21/2012 06:47 AM, Josselin Mouette wrote: For some pieces of the system, “down to Windows level” would be quite an improvement. Are you suggesting that we replace the start menu by a Sokoban game? Sorry, couldn't resist... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503314b1.8030...@debian.org
