Intel and XMir
Intel and XMir
Posted Sep 11, 2013 15:10 UTC (Wed) by ovitters (guest, #27950)In reply to: Intel and XMir by lkundrak
Parent article: Intel and XMir
For a long time it was impossible to do any Mir development if not running Ubuntu. Meaning, there were 0 instructions on how to build it and it required patches all over the place.
Seems unrealistic expectations to have Unity or Mir working on Fedora. The focus within Canonical is foremost on Ubuntu, all other distributions are secondary. Not saying it does not happen one day (IIRC Unity nowadays is much easier to get working).
Posted Sep 11, 2013 15:24 UTC (Wed)
by maxiaojun (guest, #91482)
[Link] (71 responses)
The focus within Red Hat is foremost on Fedora, all other distributions are secondary.
Posted Sep 11, 2013 15:35 UTC (Wed)
by ovitters (guest, #27950)
[Link] (27 responses)
Would be nice to investigate a little bit before saying something on LWN. There are a lot of people who do not mind to investigate.
Posted Sep 12, 2013 2:34 UTC (Thu)
by daniels (subscriber, #16193)
[Link] (1 responses)
You think this is bad? Try the Phoronix forums.
Posted Sep 15, 2013 4:22 UTC (Sun)
by rahvin (guest, #16953)
[Link]
Posted Sep 12, 2013 2:57 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (18 responses)
How your "facts" make my statements wrong? You even acknowledge that Red Hat focus on their own "enterprise" distribution.
How can a billion dollar Linux company not contribute "loads and loads" of work? You really believe that Linux (kernel) is primarily contributed by hobbyists?
You may look a bit closer to IBus project ( https://code.google.com/p/ibus/ ) , and see how shitty a Red Hat backed project can be. Yes, I mean shitty.
Posted Sep 12, 2013 6:16 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Sep 12, 2013 7:36 UTC (Thu)
by ovitters (guest, #27950)
[Link] (15 responses)
I am talking about Canonical and Canonical projects. Upstart did not start out at Canonical, they just hired the main developer. Canonical focusses within just one project solely on Ubuntu. Red Hat and SuSE do not.
Regarding IBus, I don't know. Maybe out of all the projects their sponsor one is focussed solely on Fedora. That's not the case though.
You only make clear you have an issue with Red Hat. I don't care.
Posted Sep 12, 2013 8:59 UTC (Thu)
by cjwatson (subscriber, #7322)
[Link] (4 responses)
This is a curious piece of historical revisionism, and since I was there I can't let it pass.
Scott was arguably Canonical's first full-time employee (things were a little fuzzy in the very early days and he and Robert Collins had a long-running debate over who was first), hired in early 2004. To start with Scott wasn't doing anything related to init systems, and indeed wasn't initially on the "distro team" that was focusing solely on Ubuntu, but was mainly working on problems related to revision control.
In late 2004 / early 2005, Scott started working on the boot process (recall that that was the time when everyone was moving over to the various components of Project Utopia, including udev), and over a year or so of working on that he came to the conclusion that a number of problems were fundamentally unfixable without replacing the init system. At a Canonical distro team sprint in early 2006 he presented a design for a new event-based init daemon to us, and I remember going over it in considerable detail and giving him feedback on the proposed state machine (I think that was roughly when he settled on the name "Upstart" too). At UDS in June 2006 he presented this as a spec for the Ubuntu 6.10 cycle (and you can see that https://wiki.ubuntu.com/ReplacementInit?action=info lines up with this), it was one of his four specced projects for that release cycle, and we switched Ubuntu over to the new Upstart init daemon in September 2006.
Now, it's certainly fair to say that Upstart was Scott's brainchild rather than something that Canonical management asked him to do or whatever, and he did a lot of the work for it in his free time because it was something he cared about. He also did a lot of it on work time, he had many discussions with me and other Canonical employees about its design and implementation, and he felt strongly about making Ubuntu's boot process reliable as well as running it as an upstream project that other distributions could use.
Upstart would not have happened without Scott, just as many projects (corporate-backed or not) wouldn't have happened without their initial primary developers. But it is quite false to say that Canonical "just hired the main developer", as if we noticed this promising Upstart project and decided we should hire the person who'd been developing it. That's not how it happened.
Posted Sep 12, 2013 9:45 UTC (Thu)
by ovitters (guest, #27950)
[Link]
Posted Sep 13, 2013 0:57 UTC (Fri)
by jdub (guest, #27)
[Link] (2 responses)
1) David Miller (bugzilla, not kernel)
(It's Scott and I that argued over 3 and 4.)
:-)
Posted Sep 13, 2013 2:56 UTC (Fri)
by cjwatson (subscriber, #7322)
[Link] (1 responses)
Posted Sep 14, 2013 19:54 UTC (Sat)
by jbailey (guest, #16890)
[Link]
Posted Sep 12, 2013 17:18 UTC (Thu)
by kiko (subscriber, #69905)
[Link] (3 responses)
C'mon Olav.. you of all people know that there is no such thing as a company contributing code to an open source project; open source is contributed to by people, and Canonical's engineers certainly do -- regularly -- contribute code to open source projects in general. It's a small company, though, with 600 employees and about 2/3 that of engineers. If you compare that population to the size of the RHEL engineering contingent, it's no wonder their contributions upstream have less impact.
If you were saying that a) Canonical prioritizes Ubuntu as its own product and b) focuses on integration and polish as opposed to upstream features, there is absolutely no contest there. You're right -- last-mile polish is the area where the biggest gap existed in open source when it was founded, and I think Ubuntu' s success and adoption confirm it was an effective goal to pursue. I truly wish the company had more resource to invest in upstream features -- I myself miss many -- but when you are a small and yet-to-be-profitable company, focus can be a good way to avoid failure.
I know Canonical has its share of policy problems. But as a key influencer, your criticism could help us fix them, as opposed to blending them all into a big Canonical Does Nothing For Open Source meme.
Posted Sep 12, 2013 21:23 UTC (Thu)
by niner (subscriber, #26151)
[Link] (2 responses)
As an application developer, I see for example systemd as a unifying force long overdue. I've never had the time to write init scripts for distributions other than the one I use, but I can be quite sure that my systemd unit files work just about everywhere (or at least will work). Well except for Ubuntu. And sadly they do not even have any good reasons. The same story now seems to be happeing with Mir.
Posted Oct 1, 2013 12:21 UTC (Tue)
by JanC_ (guest, #34940)
[Link] (1 responses)
Posted Oct 1, 2013 12:31 UTC (Tue)
by niner (subscriber, #26151)
[Link]
[Unit]
[Service]
[Install]
There might be some obscure system where this might not work. Maybe. Small chance.
Now write a SysV init script that does the same and works on at least the major distributions. After network's up, Xvfb should be started with the given parameters and if it crashes it should be restarted. It should by default be enabled in a multi-user runlevel. And to make things interesting: do it without having these distributions to test. Bonus points for not even having to try to find distribution specific documentation.
Systemd makes this so, so, so much easier. Finally.
Posted Sep 12, 2013 20:05 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
Go and learn about it, otherwise don't claim anything about Red Hat.
Posted Sep 12, 2013 20:22 UTC (Thu)
by ovitters (guest, #27950)
[Link] (4 responses)
Anyway, I do whatever I please and please just shut the fuck up.
Posted Sep 12, 2013 20:27 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (2 responses)
Posted Sep 12, 2013 22:43 UTC (Thu)
by ean5533 (guest, #69480)
[Link]
Posted Sep 14, 2013 1:49 UTC (Sat)
by liam (guest, #84133)
[Link]
So, "volunteers" are the biggest single contributing body.
Posted Sep 12, 2013 3:49 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
At the end of day, many applications are only certificated with SLES, so nice.
Posted Sep 12, 2013 7:41 UTC (Thu)
by ovitters (guest, #27950)
[Link] (4 responses)
I can tell you: not related at all. Just saying a bunch of things and hoping something proves you right is a pretty bad strategy to have a discussion. Please, please try to stick on topic.
Regarding "many applications": this again does not relate to the huge amount of cross distribution work they do.
Posted Sep 12, 2013 20:25 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (3 responses)
> Regarding "many applications": this again does not relate to the huge amount of cross distribution work they do.
How can you justify your claim given the fact that many applications are SLES "exclusive"? When you say "huge", how do you measure it?
I do know one key contribution from SUSE, SCIM.
It might be the king of its time, after its primary author heads to Google, it suddenly became an abandon-ware.
Then it comes IBus...
Posted Sep 12, 2013 20:29 UTC (Thu)
by ovitters (guest, #27950)
[Link] (2 responses)
If you're able to respond to a claim of mine, then fine. At the moment, you keep switching topics.
You brought up Red Hat, SuSE, The topic is XMir. If you are able to say anything relevant, cool. At the moment, you're just a mosquito.
Posted Sep 12, 2013 20:34 UTC (Thu)
by corbet (editor, #1)
[Link]
Posted Sep 12, 2013 20:34 UTC (Thu)
by maxiaojun (guest, #91482)
[Link]
If you do not bother to justify your ungrounded claims, then fine, yet another liar in FOSS world.
Posted Sep 11, 2013 17:15 UTC (Wed)
by drag (guest, #31333)
[Link] (42 responses)
That's pretty much BS. Redhat has had a good track record of working changes into upstream for the various projects they work on and they open source their software fairly aggressively. Canonical does not.
Redhat is not perfect, of course. However, juxtaposing words around in a juvenile manner isn't a way you win a arguments or convince people of your position.
----
That being said I see absolutely no reason at all why Canonical should be obligated to work with other distributions, nor why they should be condemned if they choose not to make their software portable.
There are very significant penalties you pay when you want to make your software portable across all Linux distributions and getting distributions to package it. You have to deal with politics, inane and petty differences between distributions, some significant technical issues, coordinating efforts, packaging, testing... etc etc. You are going to increase the complexity significantly by taking that approach. It's going slow down performance, slow down improvements, increase complexities, increase bug counts, lose of control, etc etc. There is also significant overhead in just trying to get people to agree to your approach. You will be spending a lot of your time and money doing things that provide almost no direct benefit to your project or your users.
So if the benefits of concentrating on portable software (ie. Wider audience, more participation from third party developers, etc) do not outweigh the obvious negatives, then there is no point to pursuing it. If you are going that direction (not pursuing third party distribution participation) then, unfortunately, you do not really have any right to complain when you try to place a maintenance burden on other people not involved in your project.
Canonical should neither feel guilty nor be condemned for wanting to work on their own stuff in their own way. Their approach may work out. But if that is what they want and the way things they are going then everybody just needs to be honest and accept this is what they are doing and not blame third parties for not accepting burdens for Canonical.
If Canonical is not taking this approach (ie. being Unity/Ubuntu-specific) and they really want Mir to be widely adopted by other distributions then they are going to have to go out of their way to try to make that happen and be fully prepared to abandon Mir if their approach is not adopted by a wide audience.
In addition, and going a bit off-topic, I think that in the long-run that Linux-land would be far better off dealing with two isolated and unique application stacks then dealing with a thousand possible combinations of this or that.
Posted Sep 12, 2013 3:11 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (40 responses)
No.
Red Hat has a good record of control various upstreams by implanting their employees, throwing whatever shit they come up into Fedora and probably fixing some problems when RHEL release is close (for example GNOME Classic mode).
Sure, the works are open source. It follows that API/ABI stability receives zero respect. Programs work today may not even build tomorrow.
Posted Sep 12, 2013 14:48 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (37 responses)
Sure, you have more people contributing to upstream projects, then I suppose by virtue of those contributions you have some influence over the direction of those projects.
But it may surprise you there is no corporate agenda as such behind this. There was no memo telling us what to think about mir (or systemd or gnome-shell or ... in fact there are outspoken RH employees on both sides of the systemd and gnome-shell debates.). It is just that RH see the benefit of a healthy upstream and making contributions to upstream projects.
I fail to see a problem in that. But I suppose some people see controversy where they want to see it.
> Sure, the works are open source. It follows that API/ABI stability receives zero respect. Programs work today may not even build tomorrow.
no, that doesn't actually follow, but whatever, I guess I shouldn't feed the troll
Posted Sep 12, 2013 20:59 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (36 responses)
The problem is that, well, even if RH doesn't have consensus internally, as you mentioned, an external entity, e.g., Canonical, would be bashed by many people if they do not follow the direction of systemd and/or gnome-shell.
As a matter of fact, Lennart explicitly called Canonical to adopt systemd on Google+. If it is even OK within RH to dislike systemd, what's wrong with Canonical if they decide to keep UpStart around for some time?
> no, that doesn't actually follow
Yes, it doesn't follow in strict logical sense. However, after observing numerous breakage caused by GTK+ and so on, after some very bad experience about PyGTK, I'd conclude that the "open source atomsphere" does contribute to the loose API/ABI stability we are experiencing today.
Posted Sep 12, 2013 21:15 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
XMir is another inferior solution.
Posted Sep 12, 2013 21:25 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (17 responses)
Wayland is another inferior solution.
If you thought that only your claim is right, then explain again what is free software.
Posted Sep 12, 2013 21:30 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Mir is inferior to Wayland (still), though it's quickly gaining new functionality.
And what's worse, the decision to start Mir was purely political. There are absolutely no technical reasons for Ubuntu _not_ to use Wayland.
Posted Sep 12, 2013 21:46 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (7 responses)
Having more features doesn't mean superior.
Moreover, I once noticed that yum/zypper is probably superior to APT. Should we give up APT and switch, then?
> And what's worse, the decision to start Mir was purely political. There are absolutely no technical reasons for Ubuntu _not_ to use Wayland.
Probably true. But given the obvious hostility showed by Intel this time, I find that political concerns, if any, are justified.
Posted Sep 12, 2013 21:50 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> Moreover, I once noticed that yum/zypper is probably superior to APT. Should we give up APT and switch, then?
> Probably true. But given the obvious hostility showed by Intel this time, I find that political concerns, if any, are justified.
Posted Sep 12, 2013 22:04 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
So, how do you measure complexity?
> Intel's hostility is mostly reaction to Ubuntu's.
If not picking some free software is hostility, then free software is a misnomer of fascist software.
Posted Sep 12, 2013 22:52 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> If not picking some free software is hostility, then free software is a misnomer of fascist software.
Posted Sep 12, 2013 23:20 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (3 responses)
Oh, then it is even better to use Windows Server, where it generally requires 0 line of code to do things have 0 chance of making a mistake.
> Creating a technically pointless local fork is hostility and one of the major reasons for fragmentation.
I find that it is quite meaningful, after encountering so many hostile, fascist people like you.
Posted Sep 12, 2013 23:23 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
SystemD _is_ easier to use than Upstart, especially with its JournalD integration.
Posted Sep 12, 2013 23:33 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
Yes, you are always 100% correct.
> SystemD _is_ easier to use than Upstart, especially with its JournalD integration.
A straight search of "JournalD" gives me this: https://bbs.archlinux.org/viewtopic.php?id=168524
Posted Sep 12, 2013 23:41 UTC (Thu)
by pizza (subscriber, #46)
[Link]
You do realize that that link actually contradicts your assertion? The actual problem is another piece of software (ie nepomuk) either had corrupted data files or said files weren't compatible from one version to the next, and was continually (and rapidly) crashing and restarting itself. Journald, being the system logger, did its job and logged each and every occurance.
Posted Sep 19, 2013 5:04 UTC (Thu)
by jamesh (guest, #1159)
[Link] (2 responses)
Instead, they continued work as a new project and ended up with a product that you apparently like a lot.
Is it really that difficult to give Mir the same courtesy, and accept that its reasons for existence might not just be political?
Posted Sep 19, 2013 5:13 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 19, 2013 5:36 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
That comparison weakens your plea
http://0pointer.de/blog/projects/why.html explains why systemd was started and has the technical details of how the architecture is different and really the inverse of upstart and they still talked to upstart developers before developing an alternative.
If there are similar technical reasons for Mir or if Mir developers talked to Wayland and tried collaborating, feel free to provide pointers.
Posted Sep 12, 2013 23:32 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Sep 12, 2013 23:37 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (3 responses)
Yes, only Fedora fascist can call Ubuntu inferior, not other way around.
> So please just stfu.
Obvious troll obvious.
Posted Sep 14, 2013 23:29 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Sep 15, 2013 17:14 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
[1]This is a meta-discussion, so it probably doesn't count here.
Posted Sep 16, 2013 22:24 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Sep 12, 2013 21:34 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (2 responses)
> The problem is that, well, even if RH doesn't have consensus internally, as you mentioned, an external entity, e.g., Canonical, would be bashed by many people if they do not follow the direction of systemd and/or gnome-shell.
well, I'd phrase it a different way, ie. that RH gives a lot of freedom to employees that work on upstream projects (and really, that RH employs a lot of people who are very passionate about open source and upstream). I guess when you have a lot of people with passion and strong opinions (in and outside of RH), there may be some bashing. Don't take it too seriously.
> As a matter of fact, Lennart explicitly called Canonical to adopt systemd on Google+. If it is even OK within RH to dislike systemd, what's wrong with Canonical if they decide to keep UpStart around for some time?
I don't see any particular big problem if canonical keeps upstart.
But otoh, upstart doesn't really have a big impact on graphics stack and toolkits, so it is an area that doesn't cause as much fragmentation of effort for the linux desktop and graphics drivers. Maybe I take this more seriously because I'm a graphics driver developer... but graphics drivers are an area where we are seriously outnumbered by our closed source counterparts, and seriously understaffed. So needless fragmentation in this area is a bad thing.
>> no, that doesn't actually follow
>Yes, it doesn't follow in strict logical sense. However, after observing numerous breakage caused by GTK+ and so on, after some very bad experience about PyGTK, I'd conclude that the "open source atomsphere" does contribute to the loose API/ABI stability we are experiencing today.
Hmm, maybe a matter of bad experience with a particular project. I would say that the linux kernel has an "open source atmosphere" and it has some of the most rigorous ABI stability requirements (when it comes to userspace/kernel ABI). And likewise, the client<->xserver protocol ABI is very rigorously maintained. And the wayland crew is taking the same approach with wayland protocol.
Posted Sep 12, 2013 23:04 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
Yes, indeed.
> So needless fragmentation in this area is a bad thing.
This is unrelated. Fragmentation gonna happen when there is conflict interest. And people have right to have conflict interest.
> Hmm, maybe a matter of bad experience with a particular project. I would say that the linux kernel has an "open source atmosphere" and it has some of the most rigorous ABI stability requirements (when it comes to userspace/kernel ABI). And likewise, the client<->xserver protocol ABI is very rigorously maintained. And the wayland crew is taking the same approach with wayland protocol.
Without GTK+ and so, many interesting stuff won't build.
Posted Sep 13, 2013 0:10 UTC (Fri)
by robclark (subscriber, #74945)
[Link]
> This is unrelated. Fragmentation gonna happen when there is conflict interest. And people have right to have conflict interest.
yeah, perhaps I put it badly.. one aspect of open source / free software is the freedom to take it and try something different.
But, when that something different is something that touches many different projects which make up the (in this case, graphics) stack, you have no right to demand that those various upstream projects shoulder the burden of maintaining your changes.
And fwiw, I'd have the same negative opinion if, for example, some distro wanted to fork a different core piece of the linux ecosystem, like the kernel (cough, cough, android.. although at least in the android case there are some vaguely valid technical reasons)
>> Hmm, maybe a matter of bad experience with a particular project. I would say that the linux kernel has an "open source atmosphere" and it has some of the most rigorous ABI stability requirements (when it comes to userspace/kernel ABI). And likewise, the client<->xserver protocol ABI is very rigorously maintained. And the wayland crew is taking the same approach with wayland protocol.
> Without GTK+ and so, many interesting stuff won't build.
Ok, I guess I am missing the point you are trying to make here. But I'm not really getting the connection between "open source atmosphere" meaning that projects must have no respect for ABI compatibility (or really what has to do with this topic at all). Maybe certain projects have a problem, I'm not really involved w/ gtk+ so I don't really know the details in this particular case.
Posted Sep 13, 2013 0:25 UTC (Fri)
by daniels (subscriber, #16193)
[Link] (13 responses)
That's two years longer than the period between the initial release of Windows XP, and the release of its last service pack.
Posted Sep 16, 2013 9:23 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (9 responses)
Windows, on the other hand, still supports the same ABI and API since Windows 95. That's 18 years, and still counting.
Posted Sep 16, 2013 16:53 UTC (Mon)
by dlang (guest, #313)
[Link] (8 responses)
Posted Sep 17, 2013 7:09 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (7 responses)
Posted Sep 17, 2013 10:26 UTC (Tue)
by dlang (guest, #313)
[Link]
i also have some very old binaries on some of my Linux systems that are still working today. Some of those are graphical apps that were written for motif (although admittedly, most are command line apps)
The fact that you are having problems with GTK+ 1.2 apps has more to say about the GTK developers than Linux overall.
You will not find me defending the backwards compatibility of Desktop Environment developers, and the fact that Gnome2 and Gnome3 could not both be insalled on the same system is a perfect example of the problem (and far from the only one, it's not limited to Gnome)
Posted Sep 17, 2013 12:09 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
That said, I know Fedora (and presumably others) stopped shipping GTK-1.2 libraries by default several years ago because there's nothing in the standard install sets that uses GTK-1.2 any more. It's still available via yum for those that want/need it.
So, I'm genuinely curious as to what you are trying to run/build, and if you checked that the libraries/headers are indeed installed, and if that build error is indeed due to GTK.
And on a tangental note, I've found that Linux (via Wine) often provides better backwards compatibility for older/ancient Windows software than modern Windows does, especially for stuff written during the years of massive DirectX API churn.
Posted Sep 17, 2013 13:16 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (3 responses)
My own tools I wrote back in the day, while learning GTK+. GTK+ 1.x has not been available in Ubuntu for a long time (don't know about others), so no headers and no libraries here. Unless I compile my own, something I'm was not very inclined to do.
Posted Sep 17, 2013 13:35 UTC (Tue)
by peter-b (guest, #66996)
[Link]
Posted Sep 17, 2013 15:02 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Oct 1, 2013 12:38 UTC (Tue)
by JanC_ (guest, #34940)
[Link]
Posted Sep 19, 2013 17:33 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Sep 19, 2013 5:24 UTC (Thu)
by freetard (guest, #92836)
[Link] (2 responses)
Try compile http://i8086emu.sourceforge.net/ on any recent distribution. RHEL family doesn't count.
Posted Sep 19, 2013 7:00 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
System: Debian Stable (7.0).
Posted Sep 19, 2013 11:39 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Fedora 19 is about as recent as it gets, BTW.
Posted Sep 12, 2013 17:21 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Or to put it another way -- "The people who do the actual work get to decide the direction a project takes."
Posted Sep 12, 2013 20:44 UTC (Thu)
by maxiaojun (guest, #91482)
[Link]
If you count contribution by counting number of commits, I'm sure that Red Hat should be the "king".
But what kind of product we have at the end of day?
Posted Sep 25, 2013 18:14 UTC (Wed)
by makomk (guest, #51493)
[Link]
Red Hat aren't affected by the fact all the upstream "releases" are actually semi-working code dumps - they employ the PulseAudio developers, and they effectively make the Red Hat packages into the real release by cherry-picking the safe patches and taking regressions seriously. (They don't necessarily upstream their patches promptly either - I've encountered at least one really obnoxious bug that was patched in the Red Hat packages by Lennart Poettering but not fixed in the upstream version.)
Posted Sep 11, 2013 16:14 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link]
I'd like to run Unity. Why not.
I was running Unity on Fedora. http://fedorapeople.org/~lkundrak/unity/
Posted Sep 12, 2013 2:47 UTC (Thu)
by salimma (subscriber, #34460)
[Link] (2 responses)
To the point that even their laptop collaborations with Dell tend not to work so well when you either install another distro or upgrade major components. Canonical simply could do much, much better at collaborating upstream.
Posted Sep 12, 2013 3:20 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
I rather see this as a problem of Linux development model.
So I'm a hardware vendor, I have some drivers not in mainline yet. Can mainlining a driver to a futuristic version, say, 3.12 help me get CentOS 6 work on my laptop model?
Posted Sep 12, 2013 4:37 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Intel and XMir
The focus within SUSE is foremost on openSUSE, all other distributions are secondary.
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
2) Robert Collins
3) Jeff Waugh
4) Scott James Remnant
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Description=X Window Virtual Framebuffer
After=network.target
Type=simple
ExecStart=/usr/bin/Xvfb -screen 0 800x600x24
Restart=always
WantedBy=multi-user.target
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Perhaps both of you could stop? Please?
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
> Mir is inferior to Wayland (still), though it's quickly gaining new functionality.
Otherwise I may able to claim that KDE is superior to GNOME.
Intel and XMir
It is, if those features make common tasks less complicated.
It's definitely not completely superior. And once something better comes and the switch is not too complicated, then yes we should switch.
Intel's hostility is mostly reaction to Ubuntu's.
Intel and XMir
Intel and XMir
Lines of code to implement certain functionality and chances to make a mistake.
Creating a technically pointless local fork is hostility and one of the major reasons for fragmentation.
Intel and XMir
Intel and XMir
Intel and XMir
Something works for you doesn't necessarily works for other people (especially true in Linux eco-system as software configurations are way too many)
Intel and XMir
Something works for you doesn't necessarily works for other people (especially true in Linux eco-system as software configurations are way too many)
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
> juxtaposing words around in a juvenile manner isn't a way you win a arguments or convince people of your position.
So please just stfu.
Intel and XMir
> juxtaposing words around in a juvenile manner isn't a way you win a arguments or convince people of your position.
Yes, only systemd fascist can call Upstart inferior, not other way around.
Yes, only Wayland fascist can call Mir inferior, not other way around.
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Wol
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Notice how it contains practically no patches with workarounds for anything.
Intel and XMir
The focus within Canonical is foremost on Ubuntu, all other distributions are secondary.
Intel and XMir
Intel and XMir