F17 heads up: gnome-shell for everyone!

[rockdoctor]

Originally Posted by detox

i dont know anyone that has a single core

That's because we've never met. In addition to the Atom N270 on my netbook, there's the PIII-based server in the back room of the basement.

[dragonbite]

I just tried Fedora 16 on a couple of systems with different levels of success.

My personal laptop gave me the fallback mode. It's alright, but nothing very grand.

Then I tried it on my work laptop (Live USB) and got the full Gnome-shell! What a difference! It was nice enough I wanted to use it instead of what work requires me to use!

When I got home I tried it on my desktop which tried to run Gnome shell but ran into a problem with parts of words and stuff not rendering (don't know if it is because the monitor is a 16:10 instead of the more common 16:9 ratio).

So if 17 cleans it up for a more consistent experience (more like the full Gnome -shell now, not like the fallback) then I am definitely looking forward for it!

[AdamW]

Originally Posted by jpollard

There are other things about 15/16/17 I don't like - the overdependance on systemd/dbus, the inability to install normal services, the inability to replace services as needed (mostly for security), and the lack of support for any kind of server operation (if it works, fine, if it has a problem - tough).

I'm not quite sure what you mean by any of this, really. 'inability to install normal services'? systemd still has sysv compatibility and can launch and manage sysv services just fine. 'inability to replace services as needed'? you can enable and disable services and you can 'edit' services by placing a service with the same name in /etc/systemd/system ; systemd will use unit files in /etc in preference to ones in /lib, specifically so you can override the system-provided units. "and the lack of support for any kind of server operation"? You get as much support as you do for any other Fedora package, really - whatever support the maintainer of the package and anyone else who reads bugzilla is willing to provide.

Originally Posted by jpollard

One thing I do wish was that the virtual manager allowed for bridging and routing networks. That would make it easier to test server operation/management.

it does. you have to disable NetworkManager to do it at present, though.

[jpollard]

Originally Posted by AdamW

I'm not quite sure what you mean by any of this, really. 'inability to install normal services'? systemd still has sysv compatibility and can launch and manage sysv services just fine.

It has SOME compatibility. What it lacks is the sequencing between the SysV compatible services and those that are no longer SysV compatible. Sometimes they work, sometimes they don't. Just putting things like a 10 second delay seems to make them work. Complex services (data bases) distributed services (databases, filesystems) have a tendency to fail.

'inability to replace services as needed'? you can enable and disable services and you can 'edit' services by placing a service with the same name in /etc/systemd/system ; systemd will use unit files in /etc in preference to ones in /lib, specifically so you can override the system-provided units.

They don't work properly without hacking the crap out of the independant services. You forget that systemd takes over much of the initialization of a service, second, that all services are started simultaneously, with very little interdependent support
available.

"and the lack of support for any kind of server operation"? You get as much support as you do for any other Fedora package, really - whatever support the maintainer of the package and anyone else who reads bugzilla is willing to provide.

The maintainer of a package is not necessarily the developer of the package. The developers frequently are aiming at general support on any UNIX or UNIX like environment. And that precludes support for the tying that systemd/dbus does.

The Fedora package developer is tying the software to systemd/dbus to the point that it won't work anywhere else.

One of the problems not addressed in the overdependance of processes is that systemd will fail if dbus fails. If systemd fails, the system reboots. The over dependence on dbus for logging means that the errors generated don't get reported. The "status" of a service is also rather shy of information - the reason for an exit is not necessarily given by the exit code - filenames, reports of syntax errors, memory allocation errors...
Yes, it is supposed to be captured... but sometimes isn't. This MAY be a buffer full issue where the rest of messages sent are dumped because systemd can't empty the buffer as fast as failing services generate them (remember, all services are started simultaneously...) but can't easily tell (I'll try to simulate -someday- a bunch of failures with a fair amount of error messages to see... but each message will have to be unique to see which make it and which fail).

The basic problem of systemd is that it is trying to do a PERT analysis and monitoring of the system startup. This is a major problem when it cannot know all the dependencies, nor has the ability describe the dependencies. The only ones it can do are "before"/"after", but time dependencies get dicey, and mean you have to introduce null tasks to put multiple dependencies together. Some very basic information on PERT at http://en.wikipedia.org/wiki/PERT_chart

Right now you have go chasing the dependency list by looking at a bunch of independent files (in several locations) just to diagram how systemd interprets how it should work... before generating new events and dependencies..

PERT works for tracking small networks of tasks, but gets slow and complex as it gets larger. This is one reason why systemd is inappropriate for servers. My work was with large servers, many filesystems, LOTS of startup tasks. Easy to represent with SysV, easy to modify sequencing. Systemd - not so much. It is very difficult to properly edit a PERT network and avoid really bad results.

I still see reports of failures, one case was 200 NFS mounts... tried to do all of them at once, causing various servers to timeout due to network latency and delays, then failed to recover. From what I can see, this is because systemd cannot handle possibly extended timeouts (as specified in the fstab file) or able to sum the timeouts properly to compute the proper overall timeout.. (which isn't possible - some may/will be overlapping timeouts others will be serialized). Several workarounds may work... one is just putting all the mounts in rc.local instead. Of course, that also means that any dependent services must also be started there as well -- which defeats the purpose of systemd AND SysV init processing.

it does. you have to disable NetworkManager to do it at present, though.

Thanks. I haven't tried that yet, as my VMs are still under F14 and NetworkManager.

[AdamW]

I'm not sure why you think systemd has problems with expressing service dependencies, it has a full syntax for this. See 'man systemd.unit', under Options, especially Requires, RequiresOverridable, Requisite, Wants, BindTo, Conflicts, Before, After, WantedBy. (Also all the Condition parameters, some of which are extremely neat.)

[jpollard]

Because some of the dependencies are not available there - those just make the net more complex without making things any better.

for instance, requiring a remote service to be available - oops missing.
Serializing a single activity (such as NFS mounts) is another.

There are a number of things that cannot be known by the local system.

Even trying to work out local dependencies becomes very hard with a complex network - it requires external tools for analysis, none of which I have seen.

It is just a more complex solution than the problem requires. It is not faster, or easier to manage, or easier to document. It appears to be complexity just for the fun of complexity.

[creataphysics]

I finally got gnome shell to run on an intel 865 only in virtualbox so far. it's kinda choppy, but I'm sure it's much faster actually installed to the hard disk. i'm also positive it will only get better. amazing job.

edit: scratch that, after todays daily update I can no longer control my mouse at the login screen.
edit2: got it running on a regular partition on disk. it's very fast.

running a dell computer with an intel pentium 4 ht 3.2ghz with 2gb of ram and i belive 128mb intel 865 graphics card.

I'm going to finish the rest of the updates and see what happens. Last time the new kernel prevented my computer from starting up but that was yesterdays build.

edit3: ugh, now everything works perfect except that I cannot use my keyboard or mouse at the login screen.

[chrismurphy]

Originally Posted by detox

i think your wrong. Microsoft isnt coming out with anything inituitive lately. AFAICS linux is leading the way in tablets. ( i could be wrong ) there is more technology coming from Linux than there is in windows.

75% of the market is iOS. The rest is Android. Nothing else is a factor.

http://vator.tv/news/2011-09-22-appl...t-still-on-top

Originally Posted by chrismurphy

75% of the market is iOS. The rest is Android. Nothing else is a factor.

http://vator.tv/news/2011-09-22-appl...t-still-on-top

Apple is like Microsoft, always behind the times. IMO i think that story by Gartnet is out of touch, Android will do a much better job than Apple has, there's still Bugs in IOS that Apple hasnt fixed , just search the net and you'll find what they are

[chrismurphy]

Originally Posted by detox

Apple is like Microsoft, always behind the times. IMO i think that story by Gartnet is out of touch, Android will do a much better job than Apple has, there's still Bugs in IOS that Apple hasnt fixed , just search the net and you'll find what they are

Point is that there is another platform that wasn't mentioned which happens to currently be king of the hill, regardless of any other facts including bugs. Indeed I hope Android does well as that might be the only thing to keep Apple on its toes.

Android still has serious fragmentation problems which iOS doesn't have (for obvious reasons), and this results in many consumers running Android getting stuck running old versions because the manufacturer of their handset drags their feet.

[arowana]

Trying to figure out if running Gnome Shell software rendering is already possible in Rawhide and maybe change the repositories from f16 (with Gnome fallback mode) to f17...

Had anyone success getting Rawhide somehow running like it is described here? saw at fedoraprojects features page, here https://fedoraproject.org/wiki/Featu...ware_rendering , the percentage of completion for software rendering is stated to be 10%, whatever that means.

[arowana]

After switching from f16 to f17 i could get a glimpse at gnome-shell on an old pentium 3 notebook with ancient graphics. Of course it crashed and i assume the fallback packages got removed so the oh-no,-somethings-wrong-screen did not know how to restart the session anymore. But i am convinced g3 will run an my old notebook, so i will keep it. Nice.

[jpollard]

That will make it at least testable... when it works.

[AdamW]

as arowana says, the status in current rawhide is that the stuff is there and it works, but it's very crashy. for a week or so after ajax landed it it was actually working and pretty stable, but for the last couple weeks it's been extremely crashy, to the point of not really being usable. ajax says he's aware of the crashiness and working to fix it.

fallback mode is still in Rawhide. I don't know for sure, but I think it's not planned to go away in the really-short-term. You can still enable it by using the dconf setting or the control center toggle.

[creataphysics]

What will not be supported in particular?

When this was first announced I upgrade the specified packages and I was able to run standard gnome 3 session.

Currently, with the new nightly updates, it no longer let's me use the standard session. In the hardware-compatibility file in /usr/share/gnome-session I believe, intel graphics some number up to 825-865 are blacklisted.
So what I did was comment that line out. I logged out and then the gtk3 login window showed up this time. I was able to login, but unfortunately every single window I open does not display properly, it's either completely black or white with a shadow border.

I'm going too much into detail. What I want to know is what else should I do to fix this? It had worked properly before the more recent nightly builds, I'm sure there is a way around it.