Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Wrong version? (Score 2) 270

The linked changelog and description are for Firefox 28. For FF 30: http://www.mozilla.org/en-US/firefox/30.0/releasenotes/. Even accounting for FF's release schedule and for Slashdot delay, that's a bit much. Only important change for me as an end-user looks to be:
Ignore autocomplete="off" when offering to save passwords via the password manager (see 956906)

Comment Re:No... (Score 1) 533

Torvalds is pissed off at Kay Sievers, not at systemd and not at the systemd team. He's fine with Greg Kroah-Hartman taking over that mess until Sievers can get his shit together. I went through the original bug report and the kernel mailing list discussion when it first caught the limelight, and I think you're seeing Sievers's actions (condemnable as they are) as representative of the whole systemd team. (They maybe, in which case you need to show more than one lone post as proof.)

Comment Re:Accept, don't fight, systemd (Score 1) 533

Finding "systemctl -xb" you just realise that there actually is something neat about the system being able to understand it's own logs. Finding out that your system is failing to boot because of one directory permission (/var to the wrong user) and that it doesn't start a shell at all or anything you can debug with is just disappointing.

I guess you mean "journalctl -xb". Even so, I had an issue with a mount failing (not a critical one), and systemd dropped me into a what it called a root shell. (See #733232 for a similar situation). Of course, then the system was practically fully up, so the shell was fully functional. However, I refuse to believe that systemd can't start a shell to debug. It might not do so by default, but it can. See http://freedesktop.org/wiki/Software/systemd/Debugging/ (and https://fedoraproject.org/wiki/Systemd_early_debug_shell for what I presume is an older guide).

Comment Re:Just pointing out that Linus is usually fair (Score 1) 641

Indeed. Note what Linus says further down the thread:

>
> Well, parsing kernel cmdline by systemd is a bad idea
No, we very much expose /proc/cmdline for a reason. System services
are *supposed* to parse it, because it gives a unified way for people
to pass in various flags. The kernel doesn't complain about flags it
doesn't recognize, exactly because the kernel realizes that "hey,
maybe this flag is for something else". ...
And yes, that does include "quiet" and "debug". Parsing them and doing
something sane with them is not a bug, it's a feature. ...
And the thing is, this has never really been a problem in practice.
Because nobody minds if some kernel option like "debug" makes not only
the kernel enable debugging, but some system deamon log a bit more
too. ...
HOWEVER.

It does become a problem when you have a system service developer who
thinks the universe revolves around him, and nobody else matters, and
people sending him bug-reports are annoyances that should be ignored
rather than acknowledged and fixed. At that point, it's a problem.

It looks like Greg has stepped in as a baby-sitter for Kay, and things
are going to be fixed. And I'd really like to avoid adding hacky code
to the kernel because of Kay's continued bad behavior, so I hope this
works. But it's really sad that things like this get elevated to this
kind of situation, and I personally find it annoying that it's always
the same f*cking primadonna involved.

One of the original suggestions was utilities parsing the kernel command line was a Bad Thing (TM).

Comment Re:and... (Score 1) 196

I take issue with your "musts". The way I see it, if I want a real answer to x/y I use x/y. If I want some special meaning of / (like integer division or rounded answers or blah blah), I use //. That is good design.

Slashdot Top Deals

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Working...