Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: On Thu, Nov 22, 2012 at 11:58 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 22 Nov 2012 09:30:41 -0430 Andres Perera wrote: i'm not sure how using js for configuration files, as opposed to using a language commonly deployed for the same purpose, such as lua, presents an innate constraint on security. Firstly the article mentioned JIT preventing true randomisation. Secondly pulling in JS as a dependency even on servers is rediculous and is a language very familiar to attackers and unfamiliar to many users. It would be especially, shall we say kind to attackers utilising rop attacks. but jit isn't irreparably interleaved with js am i compromising by running luajit in interpreter mode instead of the reference implementation Almost certainly, yes. And that's not a slight against Mike Pall's skills. Complexity is the enemy of security, every time. Merely disabling a feature doesn't remove its footprint from the code base. And have you read any of those codebases? The reference Lua implementation is a model of clear programming, IMO. , moreover, would that imply that lua the language is insecure or is the specific implementation at fault? Lua-the-language is designed with implementation details in mind. When an implementation details become intolerably complex, they consider removing the feature (e.g. the new generational collector in 5.2). why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) Those syscalls are accessible in the run time environment, whether or not they're intentionally bound. And that's all that matters, at the end of the day. If intentions drove run time safety, there would never be attacks against real-world code.
Re: upstream vendors and why they can be really harmful
On Fri, Nov 23, 2012 at 5:11 AM, Marc Espie es...@nerim.net wrote: On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) [...] i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() you're only talking about one small aspect of security. Just because your javascript apps cannot interact with your OS doesn't make them secure. They also have to be reliable, not trample on each other memory, so that you get predictable behavior and only have to worry about logic errors in each app. People are *relying* on javascript to do real work. If you're depositing documents on servers. If you're using gmail. If you're using any kind of web app, basically. Every day, people say that high-level languages like java or js are more secure. They are missing the point. Just because they don't have buffer overflows doesn't protect them from sloppy developer errors. Just the opposite, actually: being stupid is no longer a barrier to writing production code, and you end up with idiots writing code, instead of being stopped right away by C's nastiness. Guys are not probably reading you enough. See http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg0.html and https://news.ycombinator.com/item?id=4821488 :-)
Re: upstream vendors and why they can be really harmful
Guys are not probably reading you enough. See http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg0.html and https://news.ycombinator.com/item?id=4821488 :-) Can you please take this to another mailing list or off-list? Developer's Lists These lists are for technical discussions of aspects of OpenBSD. Thanks.
Re: upstream vendors and why they can be really harmful
Follow-up interview, much better to say what you want instead of having people interpret your email. Do you know polkit (which I believe is cross platform but I prefer to remove it, primarily because it gives little indication of what is allowed and requires constant review, unlike sudo) now uses Javascript for it's configuration files because the author (from his blog) believed JS to be the most universal language he could think of. I'm still unsure if he's serious or just taking the piss. I'm sure though he writes security software, he didn't realise any security ramifications in any case. Anyway sorry to lower the tone. Cross polination and health is important. Less can certainly be more and mean more sooner for everyone. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: upstream vendors and why they can be really harmful
i'm not sure how using js for configuration files, as opposed to using a language commonly deployed for the same purpose, such as lua, presents an innate constraint on security. if i'm somehow expected to ignore how unlikely it is for the configuration vm to: a. intentionally have the ability of boundlessly influencing program behavior, or b. provide exploits that aid users with the privileges required for configuring said program in boundlessly influencing program behaviour, and that said person even has the incentive to do so (maybe in your site sudo configuration files are generated from entries to pub/guestbook.html?) then i would point out that, if anything, a popular js implementation receives broader testing than sudo's dsl. On Thu, Nov 22, 2012 at 9:04 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Follow-up interview, much better to say what you want instead of having people interpret your email. Do you know polkit (which I believe is cross platform but I prefer to remove it, primarily because it gives little indication of what is allowed and requires constant review, unlike sudo) now uses Javascript for it's configuration files because the author (from his blog) believed JS to be the most universal language he could think of. I'm still unsure if he's serious or just taking the piss. I'm sure though he writes security software, he didn't realise any security ramifications in any case. Anyway sorry to lower the tone. Cross polination and health is important. Less can certainly be more and mean more sooner for everyone. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: upstream vendors and why they can be really harmful
On Thu, 22 Nov 2012 09:30:41 -0430 Andres Perera wrote: i'm not sure how using js for configuration files, as opposed to using a language commonly deployed for the same purpose, such as lua, presents an innate constraint on security. Firstly the article mentioned JIT preventing true randomisation. Secondly pulling in JS as a dependency even on servers is rediculous and is a language very familiar to attackers and unfamiliar to many users. It would be especially, shall we say kind to attackers utilising rop attacks. then i would point out that, if anything, a popular js implementation receives broader testing than sudo's dsl. And it needs it and turns up bugs every week and grows constantly. Are you serious!
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 11:58 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 22 Nov 2012 09:30:41 -0430 Andres Perera wrote: i'm not sure how using js for configuration files, as opposed to using a language commonly deployed for the same purpose, such as lua, presents an innate constraint on security. Firstly the article mentioned JIT preventing true randomisation. Secondly pulling in JS as a dependency even on servers is rediculous and is a language very familiar to attackers and unfamiliar to many users. It would be especially, shall we say kind to attackers utilising rop attacks. but jit isn't irreparably interleaved with js am i compromising by running luajit in interpreter mode instead of the reference implementation, moreover, would that imply that lua the language is insecure or is the specific implementation at fault? why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) then i would point out that, if anything, a popular js implementation receives broader testing than sudo's dsl. And it needs it and turns up bugs every week and grows constantly. Are you serious! i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() what now?
Re: upstream vendors and why they can be really harmful
On Thu, 22 Nov 2012 13:27:46 -0430 Andres Perera wrote: but jit isn't irreparably interleaved with js The latest polkit actually depends on the javascript package. am i compromising by running luajit in interpreter mode instead of the reference implementation, moreover, would that imply that lua the language is insecure or is the specific implementation at fault? why would the runtime be attractive for rop? having the javscript package on your system when you otherwise wouldn't can allow an attacker to use code he is likely familiar with return to libc style to modify the capability of code marked executable. This may not generally mean that much but on a small server or embedded system it may mean a lot. The main point is that this is an example of a Redhat developer having free reign to do silly things and actually increased the difficulty of the average human configuring polkit and without evaluating all potential consequences and scenarios. POSIX being influenced by such things is wrong. p.s. When I said polkit is cross-platform, I really meant it's portable.
Re: upstream vendors and why they can be really harmful
On Thu, 22 Nov 2012 14:18:59 -0430 Andres Perera wrote: there's still no tie-in to the privileges of the process, It still lets a process do something unintended. In fact getting a browser to execute an external javascript program is a threat in itself that could have no end of custom instructions executed as a normal user. as explained in my previous message, and there's also a new, pending tie-in; POSIX being influenced by such things -- i doubt that js is creeping its merry way into posix. Your twisting my meaning and I'm sure we're just boring everyone and polluting this thread for sure now and this is @tech.
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 2:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 22 Nov 2012 14:18:59 -0430 Andres Perera wrote: there's still no tie-in to the privileges of the process, It still lets a process do something unintended. In fact getting a browser to execute an external javascript program is a threat in itself that could have no end of custom instructions executed as a normal user. something unintended like fiddling with its registers and increasing $pc in gdb In fact getting a browser to execute an external javascript program is a threat in itself that could have no end of custom instructions executed as a normal user. i'm convinced that you don't know what javascript is and in spite of that decided that it carries along the dom apis wherever it goes, like some sort of disfunctional sidekick relationship ala robin and batman as explained in my previous message, and there's also a new, pending tie-in; POSIX being influenced by such things -- i doubt that js is creeping its merry way into posix. Your twisting my meaning and I'm sure we're just boring everyone and polluting this thread for sure now and this is @tech. that's just the pussiest way of saying i've mistakenly sprayed my comments with acronyms like rop and jit, but i have no fucking clue how they relate
Re: upstream vendors and why they can be really harmful
On Thu, 22 Nov 2012 15:58:12 -0430 Andres Perera andre...@zoho.com wrote: On Thu, Nov 22, 2012 at 2:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 22 Nov 2012 14:18:59 -0430 Andres Perera wrote: there's still no tie-in to the privileges of the process, It still lets a process do something unintended. In fact getting a browser to execute an external javascript program is a threat in itself that could have no end of custom instructions executed as a normal user. something unintended like fiddling with its registers and increasing $pc in gdb No In fact getting a browser to execute an external javascript program is a threat in itself that could have no end of custom instructions executed as a normal user. i'm convinced that you don't know what javascript is and in spite of that decided that it carries along the dom apis wherever it goes, like some sort of disfunctional sidekick relationship ala robin and batman Like shell, do you have any idea how much js is capable of. And yes in my opinion all interpreters should honour noexec and Sudo does not depend on shell but anyway that was a bonus point to the unnecessary problem introduced due to lack of collaboration with bodies of differing backgrounds or almost anyone but Zeuthen in this case. as explained in my previous message, and there's also a new, pending tie-in; POSIX being influenced by such things -- i doubt that js is creeping its merry way into posix. Your twisting my meaning and I'm sure we're just boring everyone and polluting this thread for sure now and this is @tech. that's just the pussiest way of saying i've mistakenly sprayed my comments with acronyms like rop and jit, but i have no fucking clue how they relate I know what I have said and understand it just fine. If you would like to pick out something specific even though it is besides the main point then I shall elaborate but please reply on misc@.
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) [...] i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() you're only talking about one small aspect of security. Just because your javascript apps cannot interact with your OS doesn't make them secure. They also have to be reliable, not trample on each other memory, so that you get predictable behavior and only have to worry about logic errors in each app. People are *relying* on javascript to do real work. If you're depositing documents on servers. If you're using gmail. If you're using any kind of web app, basically. Every day, people say that high-level languages like java or js are more secure. They are missing the point. Just because they don't have buffer overflows doesn't protect them from sloppy developer errors. Just the opposite, actually: being stupid is no longer a barrier to writing production code, and you end up with idiots writing code, instead of being stopped right away by C's nastiness.
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 11:41 PM, Marc Espie es...@nerim.net wrote: On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) [...] i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() You're only talking about one small aspect of security. Just because your javascript apps cannot interact with your OS doesn't make them secure. that's not a specialized condition reserved to js interpreters, and i also don't wish to talk about larger aspects because i'd be entering an area that's dominated by quality of implementation issues that aren't solved by os access control tools They also have to be reliable, not trample on each other memory, so that you get predictable behavior and only have to worry about logic errors in each app. same applies People are *relying* on javascript to do real work. If you're depositing documents on servers. If you're using gmail. If you're using any kind of web app, basically. that's interesting. the subject is about a potential configuration language that is managed by the administrator, such as polkit's and sudo's Every day, people say that high-level languages like java or js are more secure. They are missing the point. Just because they don't have buffer overflows doesn't protect them from sloppy developer errors. Just the opposite, actually: being stupid is no longer a barrier to writing production code, and you end up with idiots writing code, instead of being stopped right away by C's nastiness. every time i pair malloc() with free(), i don't feel enlightened; i don't feel like wallowing in thoughts of my own self-worth; i don't feel like masturbating intellectually i should know by now, given that i'm 3 months into rewriting infrastrusture/bin/dpb in C
Re: upstream vendors and why they can be really harmful
sickmind at lavabit.com writes: As far as I know they are going to release their own linux distro called GNOME OS with it's own API (GNOME API) and stuff. In this case making GNOME incompatible with everything else and all that talk about brands and marketing both make sense. From https://trac.transmissionbt.com/ticket/3685#comment:4 I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry. It is my hope that you are a GNOME app. Yes this kind of fragmentation is unfortunate. I'm not happy about it either. Anyway, I just wanted to give you a heads up. Wish you the best. How dirty! If you assume XFCE can have an app, you sure know what XFCE is! Isn't it a hypocrisy that GNOME people trade fragmentation in one hand and be-my-app salvation in another with all-understanding faces? Let's be straight: * Not a GNOME app? You will be unable to use notification area. * Not a systemd app? You will be unable to run at all. In other words you either an app, or dead one. What I see here is GNOME and Ubuntu building their own sandboxes, like Apple Store, Android Market, Ovi Store, name it. So first of all they need to turn portable applications into not-so-portable apps. This effectively means open source software placed into a sandbox under single App Store EULA. Another interesting thing is Zuck condemned HTML5 (another way to build portable applications) in favor of native apps. No doubts FacePhones and FacePads will have native Facebook Apps. Cheers, Alexey
Re: upstream vendors and why they can be really harmful
On Thu, 8 Nov 2012 10:18:28 +0100 Lars von den Driesch wrote: The only distros with a fair few users who have switched and still have far less users are Fedora, Mageia and OpenSUSE. Let's have an eye on Arch-Linux. And they have lost users over it. I left them out because they have few users in comparison. What do you mean by having an eye? To me, Arch has absolutely zero bearing on what I have said? Well, then probably I didn't get what you wanted to say. The main point was that systemd advocates constantly re-iterate FUD that systemd is inevitable and you are/will be in the minority if you don't switch. I'm complicatedly pointing out that actually systemd systems will be in the vast minority for the foreseeable future. I just know I am reading this list because Arch switched to systemd and I am looking for alternatives. Good Luck. OpenBSD is brill, but there is a learning curve (updating etc..) and less devs than ideal but less devs has it's quality merits too (has many more devs than arch though). Sabayon Server may make a good start as a replacement for Arch also?
Re: upstream vendors and why they can be really harmful
synchronicity, seen thx to Bruno Rohee... https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/
Re: upstream vendors and why they can be really harmful
On Thu, Nov 8, 2012 at 2:21 PM, Marc Espie es...@nerim.net wrote: synchronicity, seen thx to Bruno Rohee... https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ Marketing? Brand presence? Visual identity? WTF?!? The following, in particular, is a little gem: The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one? How is this fucking insane? A Microsoft marketing manager couldn't do better ;)
Re: upstream vendors and why they can be really harmful
On 15:01 Thu 08 Nov , David Coppa wrote: On Thu, Nov 8, 2012 at 2:21 PM, Marc Espie es...@nerim.net wrote: synchronicity, seen thx to Bruno Rohee... https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ Marketing? Brand presence? Visual identity? WTF?!? The following, in particular, is a little gem: The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one? How is this fucking insane? A Microsoft marketing manager couldn't do better ;) As far as I know they are going to release their own linux distro called GNOME OS with it's own API (GNOME API) and stuff. In this case making GNOME incompatible with everything else and all that talk about brands and marketing both make sense.
Re: upstream vendors and why they can be really harmful
and if you come with proper arguments (and code) they will be more than happy to include it or change the way they do things to accomodate to standards. Lennart is a different matter, he made it clear he doesn't care about the rest of the ecosystem. But he is just one guy and his lobbying works also because no one else is here to challenge him. It's one thing to rant on mailing list and blobs... I know Lennart comes out with some right rubbish and utterly pointless and misleading hype from this link but whether he is pulling strings I do not know and in any case does not change the facts. http://0pointer.de/blog/projects/security.html It's stated time and again that if you are a Linux distro you will have to switch to systemd sooner or later. It was even said on this list debian will switch without giving evidence, was it the hype?. I welcome any recent links to contradict me? You get a similar thing in football, if some say someones the best defender enough times, even if they are judging him on his shooting ability then many believe it. Something that's cost England dearly. The limited decision process I saw from the debian leader said let's wait ten years and consider openrc in the meantime and it wasn't just because debian has BSD interests. http://lwn.net/Articles/512719/ Aside from systemd being slated technically on the Gentoo and also the Sabayon lists (http://lists.sabayon.org/pipermail/devel/2012-August/008278.html) Gentoo have said something like, we are about freedom and as systemd is curtailing that we are more likely to drop Gnome than support a default of systemd. Of course as choice is our main goal we hope systemd will run too, it will just be unsupported. As I have said I don't think anyone knows the figure but if Gnome becomes dependent on systemd, they are isolating most of their potential user base provided by Debian, Ubuntu and Gentoo and it's livecd derivitives and sending half their users over to the likes of KDE/XFCE that have already gnudged ahead. The only distros with a fair few users who have switched and still have far less users are Fedora, Mageia and OpenSUSE. So there are many many annoyed by this and it should hit true, especially as KDE has apparently already overtaken Gnome as the most used desktop. I just hope you get your answer sooner but from Gnomes recent record, I'd be worried too, so Good luck and keep us informed please. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 06:24:58PM -0200, Daniel Bolgheroni wrote: On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... This IS the main problem. The BSDs definitely need to find a way to join the inner circle at the Open Group. Or maybe there are already BSD developers there. It's hard to know as an outsider because the process is so opaque.
Re: upstream vendors and why they can be really harmful
On Wed, Nov 7, 2012 at 9:40 PM, William Ahern will...@25thandclement.com wrote: On Tue, Nov 06, 2012 at 06:24:58PM -0200, Daniel Bolgheroni wrote: On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... This IS the main problem. The BSDs definitely need to find a way to join the inner circle at the Open Group. Or maybe there are already BSD developers there. It's hard to know as an outsider because the process is so opaque. Here you can read what Linux devs think about Dfly for example https://plus.google.com/101384639386588513837/posts/Dkb8iixE4eP
Re: upstream vendors and why they can be really harmful
Tomas Bodzar [tomas.bod...@gmail.com] wrote: Here you can read what Linux devs think about Dfly for example https://plus.google.com/101384639386588513837/posts/Dkb8iixE4eP Yes, let's all work on Linux!!! Let's all move to Texas. And, what's with this water? Like in the toilets? What about Brawndo?
Re: upstream vendors and why they can be really harmful
On Wed, 7 Nov 2012 22:52:19 +0100 Lars von den Driesch larsvondendrie...@gmail.com wrote: The only distros with a fair few users who have switched and still have far less users are Fedora, Mageia and OpenSUSE. Let's have an eye on Arch-Linux. And they have lost users over it. I left them out because they have few users in comparison. What do you mean by having an eye? To me, Arch has absolutely zero bearing on what I have said?
upstream vendors and why they can be really harmful
Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine...
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine... One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. -- Antoine
Re: upstream vendors and why they can be really harmful
Apparently branding as a priority by some devs, is a major reason. I can't believe a Gnome dev said he hadn't heard of XFCE to a transmission dev! http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine... It could well end up the other way around, with systemd dying. It does far too much and most of which is pointless in order to gain traction but also limiting it's scope and so success unless it is forked or radically changed of course. The amount of code running as root is rediculous too. Even Redhat devs have said it offers little and it certainly causes major problems even for Linux. The Linux communities are still keeping some freedom (Gentoo, Debian). It's said Debian is just because of HURD but I don't think that's true, though the argument would be long. Rather than spending time on these, are trinity and mate etc.. worth looking at? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. ... Relevant LWN.net article: http://lwn.net/Articles/520892/
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:15:04PM +, Kevin Chadwick wrote: Rather than spending time on these, are trinity and mate etc.. worth looking at? I'm pretty sure trinity is worth looking at, haven't had nearly enough time to do so, especially since it's yet another build system you need to dive into.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:43:50PM +0100, Antoine Jacoutot wrote: One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. Been there, done that... I've spent quite some time trying to work with the FSF on tools like GCC. At some point, I've mostly given up, I'm not patient enough. The GCC rules were as follows: - all development happens on their -current branch, which was often a few years from making a release. - it takes sometimes months until you get an answer on a patch. Very often, it's about some style nits that they could have given you right away. (but since you're not a 1st tier, nor 2nd tier platform, be already happy you got an answer). - by which time, -current does no longer compile on your platform, due to some other issue, which obviously doesn't affect linux, but that you have no way to fix, as it is deep within the compiler. File a bug-report.. - with luck, another 3 months later, somebody fixed -current, and it works again. By which time your initial patch (which was never committed) no longer applies at all, and you're stranded, having to do it all over again. - also, you have an assurance that that work will only show up in released versions a few years from now, as they never backport anything but very critical fixes to old versions (and by definition, OpenBSD is never critical). they also made some technical choice, such as making it impossible to build gcc without gnu-make, that we never had sufficient clout to battle... I'm very happy to let pascal@ or kettenis@ deal with them directly. I don't have the patience to fight that particular fight anymore...
Re: upstream vendors and why they can be really harmful
On 11/06/2012 03:45 PM, Marc Espie wrote: On Tue, Nov 06, 2012 at 01:43:50PM +0100, Antoine Jacoutot wrote: One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. Been there, done that... I've spent quite some time trying to work with the FSF on tools like GCC. At some point, I've mostly given up, I'm not patient enough. The GCC rules were as follows: - all development happens on their -current branch, which was often a few years from making a release. - it takes sometimes months until you get an answer on a patch. Very often, it's about some style nits that they could have given you right away. (but since you're not a 1st tier, nor 2nd tier platform, be already happy you got an answer). - by which time, -current does no longer compile on your platform, due to some other issue, which obviously doesn't affect linux, but that you have no way to fix, as it is deep within the compiler. File a bug-report.. - with luck, another 3 months later, somebody fixed -current, and it works again. By which time your initial patch (which was never committed) no longer applies at all, and you're stranded, having to do it all over again. - also, you have an assurance that that work will only show up in released versions a few years from now, as they never backport anything but very critical fixes to old versions (and by definition, OpenBSD is never critical). they also made some technical choice, such as making it impossible to build gcc without gnu-make, that we never had sufficient clout to battle... I'm very happy to let pascal@ or kettenis@ deal with them directly. I don't have the patience to fight that particular fight anymore... forgive my curiosity, but is pcc anywhere near?
Re: upstream vendors and why they can be really harmful
Lets be honest, half the problem goes away if Lennart stops hacking.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'll fill in redhat, making upstream support even for older ATI video cards effectively Linux-only by removing all UMS support from the X driver: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=50689ec8dbd4a68527b2ac16cecac298b8d441d0 I'm not an X hacker so I might have misunderstood the impact of this but on the surface it looks like a move that's bad for everyone but Linux. Couldn't they at least have left the existing and working UMS stuff alone so others could still easily upgrade the driver to get bug fixes? On the bright side, somebody seems to have finally figured out the zaphod mode issue: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=20bfc652ce40008ea561db2984bccf137409c7fd
Re: upstream vendors and why they can be really harmful
On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie es...@nerim.net wrote: This is a mindset we need to fight, and this has to be a grass-roots movement. I agree with most of your statement, but for a grass-root movement you will need to attract a lot of people. Otherwise you will move exactly *nothing*. And let's be honest here - some people involved in OpenBSD are not the most open-minded people in FOSS. They behave so elitist they scare a lot of folks away and to gain momentum you will need to deal also with people that are probably not as knowledegable as you might want. If you want people to gain traction you will need to reduce some standards... just my 2 ct Lars
Re: upstream vendors and why they can be really harmful
On 2012 Nov 06 (Tue) at 16:45:17 +0100 (+0100), Lars von den Driesch wrote: :If you want people to gain traction you will need to :reduce some standards... This is exactly what happened in Linux-land, and brought us to this place in the first point. -- Math is like love -- a simple idea but it can get complicated. -- R. Drabek
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 04:45:17PM +0100, Lars von den Driesch wrote: On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie es...@nerim.net wrote: This is a mindset we need to fight, and this has to be a grass-roots movement. I agree with most of your statement, but for a grass-root movement you will need to attract a lot of people. Otherwise you will move exactly *nothing*. And let's be honest here - some people involved in OpenBSD are not the most open-minded people in FOSS. They behave so elitist they scare a lot of folks away and to gain momentum you will need to deal also with people that are probably not as knowledegable as you might want. If you want people to gain traction you will need to reduce some standards... just my 2 ct Lars Actually, I am just giving food for thought, it's a long-time issue I've seen creep up again and again... so I've tried to formalize it up to some extent. I'm not going to go out and do anything such as organize such a movement: I already don't have enough time to do everything I wish to do, and I'm pretty sure my time is much better employed writing code and fixing issues within OpenBSD, or going to conferences and explaining to people why what we do is still relevant. Also, my day job involves some teaching (a lot), so doing more of that is not really fun. So, hey, do whatever you want with that. Apart from the proverbial curmudgeons, there are LOTS of nice people in the OpenBSD developer community, who are fairly open to a lot of stuff... I wouldn't be there if that weren't the case.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 6, 2012 at 5:10 PM, Peter Hessler phess...@theapt.org wrote: On 2012 Nov 06 (Tue) at 16:45:17 +0100 (+0100), Lars von den Driesch wrote: This is exactly what happened in Linux-land, and brought us to this place in the first point. I know :-) And I understand this - but in this situation I believe you have to choose between 2 devils. If you stay in your niche you can just watch the idiocy happening outside, but you will have absolutely no way of influencing it. Lars
Re: upstream vendors and why they can be really harmful
Hi Marc On Tue, Nov 6, 2012 at 5:16 PM, Marc Espie es...@nerim.net wrote: So, hey, do whatever you want with that. Apart from the proverbial curmudgeons, there are LOTS of nice people in the OpenBSD developer community, who are fairly open to a lot of stuff... I wouldn't be there if that weren't the case. Oh, I didn't want to generalize on the niceness (or lack of) in OpenBSD - sorry if it sounded like that. As in every group there are people more friendly than others :-) From your point of view everybody is nice to you ;-) You are one of the core devs - for people probably not that knowledgable as you and coming from outside it might leave a different impression. Again, I am just saying... ;-) Lars
Re: upstream vendors and why they can be really harmful
From your point of view everybody is nice to you ;-) I'm not! Miod
Re: upstream vendors and why they can be really harmful
On Tue, Nov 6, 2012 at 1:43 PM, Antoine Jacoutot ajacou...@bsdfrog.org wrote: On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine... One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !linux people should get involved in outside projects... I'm not saying I agree nor disagree with that statement, I'm just being the devil's advocate. -- Antoine I was reading your post to Gnome mailing list and answers from devs and it's hard to find proper words on their clever answers. They are probably not much aware about your work in M:tier with Gnome, do they? They don't simply care about downstream and they already decided (most of them). Do you have some escape plan for that like some BSD licensed window manager as you are tweaking on Gnome desktop for OpenBSD anyway like WiFi GUI app? I think (can be completely out of course) that there may be pretty good interest in BSD community for some desktop like you are doing for implementation at homes, jobs and so on which is not so different from what people know from other platforms. Not like getting over 1% of Linux market share, but simply, clean and stable desktop for corporate world which can help with more attraction.
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:15:04PM +, Kevin Chadwick wrote: It could well end up the other way around, with systemd dying. It does far too much and most of which is pointless in order to gain traction but also limiting it's scope and so success unless it is forked or radically changed of course. The amount of code running as root is rediculous too. Even Redhat devs have said it offers little and it certainly causes major problems even for Linux. Some RH guys don't like only from sysadmin or job point of view, in F19 there should be no /var/log/messages or they are worried about how to support environments and apps which uses this files to parse it. This also contains big finantial level but as Fedora is playground nobody cares there much about this topic. Most Linux distros will move to systemd anyway, even Debian I bet. They already moved to stupid Upstart (like RHEL 6 IIRC). jirib
Re: upstream vendors and why they can be really harmful
I hear you on this, thinking about it I'd like to ask you what would be a solution to this rather recurrent issue/problem we're facing from the Linux side of the spectrum? What would be a solution or a framework that could somehow negate most of the effects of this particular problem?. I grew up tired as well from this bs that clearly affects OpenBSD appeal to the masses. But, in life I've learned to make decisions, and no decision is free and I just pay the bill and live peacefully away from bullshit and bad software. On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie es...@nerim.net wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not a problem. This is a mindset we need to fight, and this has to be a grass-roots movement. The main effect of THAT attitude is to *HURT* the opensource community, big time. It's as harmful as the patent portfolio of big business. Basically, it precludes smaller players from playing on a level field. As soon as you're different enough (and that's mostly NOT linux these days), you can't keep up. Those distribution problems are LARGE. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It takes a lot of manpower to address complex distribution issues. If you don't have tens of people, it becomes more and more of a losing battle, actually... It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... in some cases, you even have some people, who are PAID by some vendors, agressively pushing GRATUITOUS, non compatible changes. I won't say names, but you guys can fill the blanks in. I'm pretty sure there's a lot of good intention behind the progress in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pionneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine...
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 08:42:48PM +0100, TAKRIZ wrote: I hear you on this, thinking about it I'd like to ask you what would be a solution to this rather recurrent issue/problem we're facing from the Linux side of the spectrum? What would be a solution or a framework that could somehow negate most of the effects of this particular problem?. I grew up tired as well from this bs that clearly affects OpenBSD appeal to the masses. But, in life I've learned to make decisions, and no decision is free and I just pay the bill and live peacefully away from bullshit and bad software. Maybe I should be MORE explicit about this. I don't have ANY KIND OF SOLUTION. I know what the problem is (I think), and I don't think I'm part of the solution. I think that people talking about it, asking gnome/kde/whatever to solve the distribution issue (partly) might be the solution. Heck, the problem *in the first place* is that OpenBSD is *below some critical mass* developer-wise to *really* affect that state of being. Now, you are asking *me*, as an overbooked, overwhelmed developer, to also provide a solution for that problem ? Come on, that's something that doesn't require any of the skills I have. You guys get off your collective asses and start figuring out an actual solution. There's no need to directly involve me. Heck, there's probably little need to involve any of the current developers ! who are *all* vastly busy. It's very simple: figure out a way to get more developers involved in OpenBSD, or figure out a way to talk to gnome/kde/whatever so that we get a better chance at cooperating with them...
Re: upstream vendors and why they can be really harmful
On Tue, 6 Nov 2012 21:39:42 +0100 Marc Espie es...@nerim.net wrote: I don't have ANY KIND OF SOLUTION. Certainly couldn't for that general problem without likely being the problem. As I've said before I'm not a Gnome fan and far from a Gnome 3 fan however the reason udisks dropped many gnome features like automount for over 6 months was due to RedHats drive for multiseat which actually 99% of Linux care nothing about and perhaps has something to do with all the feature bloat and dependency issues in order to get the support from the community. Lennart has said (in a slghtly reasonable manner for once) in the thread Antoine was involved in on Gnomes list that multiseat is a large part of the portability issue. As Gnome already has dilemmas affecting user experience possibly wanting splits into. Touchscreen mode Touchscreen and mouse mode mouse mode Perhaps an Enterprise multiseat mode as well as these would atleast in my opinion and pointed out in this heise article perhaps save their bacon as the main linux desktop. http://www.h-online.com/open/features/GNOME-from-abyss-to-common-ground-1667974.html I can't see OpenBSD caring one bit about losing out on Enterprise mode ;-)
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... This IS the main problem.
Re: upstream vendors and why they can be really harmful
On Tue, 6 Nov 2012 13:38:32 +0100 Marc Espie es...@nerim.net wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? If everyone but the mainstream Linux distros dropped their projects, it seems a more likely way of getting through to the upstream developers than joining their project or sending them emails. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. Brett.
Re: upstream vendors and why they can be really harmful
Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? If everyone but the mainstream Linux distros dropped their projects, it seems a more likely way of getting through to the upstream developers than joining their project or sending them emails. eventually they get the message but sometimes its too late. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. I care about some things in kde4 like kdevelop/kate, educational apps for kids (very few mainstream distros bother for children), for qt4/5 the ability to write a single code for mobile + desktop amongst some things. There are some things in the big WMs which are missing in JWM :-) Probably other guys have different motivations.
Re: upstream vendors and why they can be really harmful
07.11.2012 2:06 полÑзоваÑÐµÐ»Ñ Brett brett.ma...@gmx.com напиÑал: On Tue, 6 Nov 2012 13:38:32 +0100 Marc Espie es...@nerim.net wrote: Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're the reason why sometimes we do drop old stuff (like killing gtk+1, and people really wanting to kill some gtk2/qt3 stuff). It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? If everyone but the mainstream Linux distros dropped their projects, it seems a more likely way of getting through to the upstream developers than joining their project or sending them emails. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. I can speak only about KDE and OpenBSD. Yes, KDE is driven mostly by Ubuntu and Fedora users. SUSE and Arch are pocking around too. FreeBSD have a whole team (4 members last time I checked) working on bringing fresh KDE 4. We have two, working part-time and semi-official. But we're in better state than Windows port already. Yes, KDE doesn't care if some functionality isn't available on other platforms. But they are at least open enough. Some time ago I've sent a patch to Konsole developers, enabling process information gathering on OpenBSD. Upstream developer tried hard to build testing environment for a few days without any request from me, and, after predictable fail, :) still committed the code. kdelibs developers accept patches happily too... Of course, there ARE developers that say Linux or losers, but you can ignore them safely, there are many other, more adequate, persons. KDE is just... huge. There is a plenty of work. But even me, not-so-knowledgeable-man, could deal with it - thanks to some decisions and actions both KDE and OpenBSD developers made and continue making. And that doesn't mean that KDE 4 wasn't usable at all until 4.6, on any platform - including Linux. :)
Re: upstream vendors and why they can be really harmful
On Wed, Nov 07, 2012 at 08:58:55AM +1100, Brett wrote: Not to disparage the hard work by Antoine and others on Gnome and KDE, but if upstream are going to entwine their code with non-standard OSs, then why bother with them? That _is_ precisely the question I asked on GNOME lists. I'm not ranting about the fact that they started requiring systemd features, it's their choice after all. Whining after it's done is pretty much useless. If you want a project you like to go in a direction that you think is better, then you need to get involved way sooner in the development process. Most of the time people rant about GNOME's direction but are not even using GNOME themselves or don't like it anyway. My real concern was to know where this was going exactly so that I could make a decision whether it would still make sense to keep working on it (which is a huge work, trust me) or not. It's not like it's the only Desktop available out there and I don't think it particularly hurts us if it were to disapear from ports; but if other more important projects (for us) follow the same direction, then it is getting problematic. I use Joe's Window Manager, it compiles in less than a minute straight from the sources with no patching or tweaking. I don't have semi-transparent windowbars and I had to make a couple of tweaks so I could hear a beep when I get an IM, apart from that, what can a modern window manager do that is worth the some porter's pain (and extra 10-20% cpu consumption to run) anyway? My cpu is idle when I'm not doing anything under GNOME. There are many reasons why a fully integrated point-and-click Desktop is attractive to some people, but this is not the topic here. Stuff like X is a different matter, if upstream must be battled, I would say send the troops to defend what is hard to do without, not what is easy to do without. Then gather your troups and go fight or provide code, because between KMS and llvmpipe we are already way way behind... Out of the 10 machines I have at home, only 1 has a fully supported X driver. The main issue is that the BSD community is very small and as espie@ mentionned, developers already have no time on their hand so it's hard to get yourself heard. Let's be pragmatic, 99% of the work is made by Linux people with no !linux developer/user being involved; why would they bother about portability if no one around challenges them? As a member of the GNOME project I can tell you that not everyone there is deaf or incompetent, and if you come with proper arguments (and code) they will be more than happy to include it or change the way they do things to accomodate to standards. Lennart is a different matter, he made it clear he doesn't care about the rest of the ecosystem. But he is just one guy and his lobbying works also because no one else is here to challenge him. It's one thing to rant on mailing list and blobs... -- Antoine
