The Three Things I Hate Most About F17...

[gflex]

Don't know for you guys, but I failed to run Fedora 17 Alpha in VMWare workstation 8.02 . Tried with default (Gnome), LXDE, XFCE ... none of them was able to start graphical mode. Hope this is matter of drivers and will get fixed soon.

[raveit65]

Originally Posted by gflex

Don't know for you guys, but I failed to run Fedora 17 Alpha in VMWare workstation 8.02 . Tried with default (Gnome), LXDE, XFCE ... none of them was able to start graphical mode. Hope this is matter of drivers and will get fixed soon.

Try virtualbox from the virtualbox repo. fc17 runs fine with 3D effects in virtualbox.

---------- Post added at 02:23 PM ---------- Previous post was at 02:15 PM ----------

Originally Posted by dd_wizard

1. No Cinnamon

2. No Mate

3. No frippery

Guess I'm stuck with gnomes-hell for now.

Everything else rocks. The pure alpha was a lot more stable than F16's was. The recent updates and a non-debug kernel makes it even more usable.

dd_wizard

I will provide Mate for fc17 too, but i wait until fc17-beta is release.
For the moment use the fc16 release rpm. You have change ' $releasever ' to '16' in the mate repo files.
It might be work.

[sdlor]

Re: Post # 17, second part..
Thank you so much, raveit65! Now I won't mind upgrading to 17, (when the time comes).

[AdamW]

jpollard: there's really no such thing as 'run last' in systemd. It's dependency based. If something you want to start requires something else to be started first, express that as a dependency.

Dependency modelling really makes a lot more sense for most services than ordering modelling. This is nicely illustrated by the fact that most admins, when dealing with sysv, do what you seem to do: default to either 'run first' or 'run last'. =)

I rather disagree on debugging, too. systemd rather bends over backwards to provide all kinds of useful tools for figuring out what it's doing. have you looked at the systemctl man page?

[jpollard]

Yup. Unfortunately, it still loses errors.

The problem with dependancy modeling is the assumption that you know all the dependancies...

Unfortunately, the provided information for all services is not known, therefore, you have to guess. Systemctl can only list dependancies that are in the configuration files... but not all dependancies are there (at least, not yet).

The next problem is that not all dependancies CAN be known for a given service. Which is one of the things that happens to NetworkManager when things get screwed up. Complex services have problems here - they may depend on things outside the local system... yet placing such dependancies into the systemd configuration doesn't seem possible. Some workarounds have been done (which is where NetworkManager-wait-online.service comes from).

Which is why rc.local doesn't run like it says - last. If it did run last then most things could be worked around just by putting it in rc.local... The only dependancy rc.local has listed is network.target. But if what is put in rc.local needs name service... welll... failure again, sometimes. Note, even in F16 named/bind is not required by network.target.... so it starts sometime after network.target is supposed to be ready. Therefore rc.local doesn't wait.

Unfortunately. So people keep putting crap in it like "sleep 5" trying to get things to work. And then it works... sometimes.

Systemd makes the assumption that just because a process is started, it is ready for use... Which is not true if it takes a second or so to identify an error. By then, the dependant process has already been started.. and also errors off. At this point, it SEEMS (this may not be true) that one or both of the error messages could be lost. I do know from looking at log files that some messages just seem to be missing.

I haven't even tried a distributed database yet. Too much is unreliable, though I am thinking about trying a single database for a web server... but will httpd wait for mysql to be usable before it tries to start? Don't think so - the only dependencies listed are syslog.target and network.target. httpd doesn't have a dependancy other than the implied network.target. Will the web server try to start making queries before or after the database is started? This can become more critical with a distributed mysql database as it can take a significant amount of time to become ready.

For simple things... it will usually work.

The problem is "usually".

[DBelton]

I believe the problem with systemd losing errors has been addressed with the systemd-journal (I believe it's supposed to be in F17, but I haven't looked to see if it is or not)

And I believe the issue with services requiring the network being started before the network is settled is actually more of a network-manager issue than a systemd issue. (Not certain on this one, yet, though) From what I have seen, it appears that network-manager is telling systemd that the network is ready when in fact it isn't.

I think quite a few of the other issues are more of a "learning curve" than actual problems, too.

Now I do agree that systemd is becoming too much of a "one application does all" which in my opinion is not good. Too much is exposed if there is a security breach, where if it was separate applications, the breach would be limited in what it could do.

(I will know before too long how systemd actually holds up from a security standpoint. Some of the heavy hitters from work have started tearing into it, having a look before it hits RHEL.)

[jpollard]

Originally Posted by DBelton

I believe the problem with systemd losing errors has been addressed with the systemd-journal (I believe it's supposed to be in F17, but I haven't looked to see if it is or not)

And I believe the issue with services requiring the network being started before the network is settled is actually more of a network-manager issue than a systemd issue. (Not certain on this one, yet, though) From what I have seen, it appears that network-manager is telling systemd that the network is ready when in fact it isn't.

I think quite a few of the other issues are more of a "learning curve" than actual problems, too.

Now I do agree that systemd is becoming too much of a "one application does all" which in my opinion is not good. Too much is exposed if there is a security breach, where if it was separate applications, the breach would be limited in what it could do.

(I will know before too long how systemd actually holds up from a security standpoint. Some of the heavy hitters from work have started tearing into it, having a look before it hits RHEL.)

As for the complexity -

A dependancy graph is an implementation of the old PERT chart. Unfortunately, the complexity growth of PERT charts rendered the technique unmaintainable due to all of the interactions within the net.

The ones I worked with (it was a school construction schedule) only had about 30 elements, each having only a two-way link. The systemd list on F16 already has 261, and that is just on my system (I do have a fair number of things installed), systemd also has many more than two links per entry possible (one of the longer has 9 just for the "After=".

I just don't see how the management of such a complex network will be possible. This was why the ordering model of SysVinit was used. It makes such complexity easier to manage.

BTW, fixing rc.local might be possible by adding "After=systemd-update-utmp-runlevel.service".. not sure, but based on that service requiring runlevel[12345].target it would look reasonable. Of course, that doesn't address the shutdown ordering...


From a security standpoint, if they can hit it, try something like a partial TCP connection to a service that uses systemd to intialize socket handling.

One place that saw a denial of service happen was with a modified inetd server - for efficency, was modified to handle all sockets for services waiting for a tcp connection (such as a listening telned service like a kerberized telnetd). In the partial connection, the inetd service would hang....

In our case, all we had to do was restart (abort/start) inetd... Can't do that with systemd without rebooting.

The cause in our case turned out to be a routing error - a connection request would come in one interface, and go out another (both were supposed to have the same connectivity). Unfortunately for us, the return path wasn't quite the same configuration - and the tcp handshake reply got dropped.

The description I was given over the systemd socket handling sounded exactly like the one in our DoS event.

Originally Posted by DBelton

I believe the problem with systemd losing errors has been addressed with the systemd-journal (I believe it's supposed to be in F17, but I haven't looked to see if it is or not)

And I believe the issue with services requiring the network being started before the network is settled is actually more of a network-manager issue than a systemd issue. (Not certain on this one, yet, though) From what I have seen, it appears that network-manager is telling systemd that the network is ready when in fact it isn't.

I think quite a few of the other issues are more of a "learning curve" than actual problems, too.

Now I do agree that systemd is becoming too much of a "one application does all" which in my opinion is not good. Too much is exposed if there is a security breach, where if it was separate applications, the breach would be limited in what it could do.

(I will know before too long how systemd actually holds up from a security standpoint. Some of the heavy hitters from work have started tearing into it, having a look before it hits RHEL.)

systemd-journal im sure now is a Fedora 18 Feature https://fedoraproject.org/wiki/Features/systemd-journal

[dd_wizard]

From the page you linked, tox:

Detailed Description

As of systemd v38+ systemd comes with it's own syslog named Journal which is enabled by default in F17 and onwards.

I'm not sure how well it works in F17, but I'm pretty sure it's there.

dd_wizard

[sea]

Havent tested F17 properly yet.
Mainly due to the first and only point that annoys me of it..

1) its 'code'-name

Originally Posted by sea

Havent tested F17 properly yet.
Mainly due to the first and only point that annoys me of it..

1) its 'code'-name

why the code name?

[sea]

beefy miracle.
To me, this is not a 'serious' code name for an OS.

[AndrewSerk]

Originally Posted by sea

Havent tested F17 properly yet.
Mainly due to the first and only point that annoys me of it..

1) its 'code'-name

What, you got something against walking talking hot dogs??

I used to have logo shown on the screen during the boot process for live cds that I made for some kids. They all commented about and said they liked it.

EDIT: http://beefymiracle.org/history.html

Originally Posted by sea

beefy miracle.
To me, this is not a 'serious' code name for an OS.

nore is Ubuntu's.but who cares , doesnt stop people from using it. prolly would stop Pamela Anderson and the rest of PETA from using it

[sea]

WTH has a hotdog to do with an OS?

1) i'm not a child
2) i'm vegetarian.

Now get me some tatar with a single malt!

Ubuntu, at least, is a 'proper' terminus or synonym for the linux community.
But aint that off-topic?
The question was: what do you hate about F17... i hate its name ... point!