Forgot your password?

Comment: Re:Please stop this madness! (Score 3, Informative) 774

by AdamWill (#48098807) Attached to: Systemd Adding Its Own Console To Linux Systems

It's been running under 'real-world conditions' for years already - do you think no-one runs real-world systems on Fedora, or that Red Hat doesn't run releases in production internally before they go out, or that RH has no customers who test pre-releases?

"Seems to me that's the largest reason it's being pushed"

Nope. I think this impression originally came from Lennart's original post on systemd, years and years ago - - because it starts out talking about boot speed. But even that very first post moves on, in the sections "Keeping Track of Processes" and later, to talk about the really interesting bits of systemd - better service management, and more capable service configuration. As systemd development continued, it's become much more about the latter and much less about boot times - I think that's where Lennart *started* thinking about systemd, but it's really not what systemd is for any more. Red Hat certainly wasn't interested in systemd because it might make servers boot three seconds faster, RH was interested because it can make service management on servers much better.

Comment: Re:Why do people care so much? (Score 3, Interesting) 774

by AdamWill (#48094227) Attached to: Systemd Adding Its Own Console To Linux Systems


systemd is designed to make it trivially simple to have text logs if you want that. RHEL 7 is configured by default to do permanent logging in plain text format via rsyslog; the native journald logs aren't even permanently stored by default (this is the config that was in Fedora for a while before journald's native format became the default/primary).

I am starting to suspect you're a troll and haven't actually used RHEL 7 at all.

Comment: Re:Why do people care so much? (Score 2) 774

by AdamWill (#48094117) Attached to: Systemd Adding Its Own Console To Linux Systems

"It does its own logging in binary which needs a tool to read the logs and if it gets corrupted then systemd's devs say "just delete the logs". Really?" They don't say that. journalctl reads as much data as it can from corrupted log files and otherwise routes around them. I don't know of any advice that says to delete them.

journald is also intentionaly designed to make it simple to store logs in plain text format if desired, using rsyslog or something similar as a journal consumer. you can do this alongside or instead of systemd's native log format.

Comment: This is rumour control, here are the facts (Score 2) 170

by AdamWill (#47855269) Attached to: Fedora To Get a New Partition Manager

Unfortunately, Mukt completely mis-reported this and Slashdot picked up their errors for the summary, which is making for a lot of confusion.


1. blivet-gui isn't supposed to (and in fact cannot) 'replace' gparted in any reasonable sense of that term.
2. blivet-gui is a new application, but its backend is the Fedora installer's storage management code, which is a very old codebase. There is no new storage management backend being written here.
3. Lennart and systemd have nothing at all to do with this.
4. It wouldn't really be practical to 'contribute' this to gparted, as it would involve completely ripping and replacing gparted's backend and then very rapidly proposing significant changes to the GUI, and hence would be a project takeover by any other name.
5. blivet uses standard underlying tools for performing operations, it's just a logic/configuration layer for them.

1: what the original announcement says is that blivet-gui uses a gparted-like UI to make it instantly familiar for gparted users. It doesn't say anything at all about it 'replacing' gparted. That's a pure invention (likely based on a misunderstanding) in the Mukt article. See the original announcement at https://lists.fedoraproject.or... to verify this, if you like. There's no sense in which blivet-gui really *could* "replace" gparted, if you think about it. gparted is an independent project; Red Hat doesn't own or maintain it, so Red Hat can't stop it existing or being maintained. gparted isn't a significant component for either RHEL or Fedora: it's just a leaf package, an app like any other. It's not like anaconda uses gparted as its partitioning tool, or anything like that. So talking about blivet-gui 'replacing' gparted doesn't make any sense, not upstream, not downstream. So long as upstream gparted devs see a need to keep developing gparted, gparted will continue to exist upstream, and so long as a Fedora packager wants gparted to be in Fedora, it'll be in Fedora, whether or not blivet-gui or any *other* storage management GUI app is also in Fedora. We have lots of space in the repos.

2: the backend for blivet-gui is blivet: (packaged in Fedora as python-blivet). This codebase is simply the storage management backend of anaconda (the Fedora installer) split out into its own repository. The split happened back in 2012: . The intent was to allow for exactly this kind of code re-use. So there really isn't some kind of new NIH effort going on here: the storage management code is not new, all that's new is the light wrapper around blivet to produce a standalone GUI app rather than using it as a part of the anaconda installer. The underlying codebase has existed basically as long as anaconda has existed, which is rather longer than gparted has existed. anaconda dates back to 1999 ( ), gparted AFAICT dates back to 2004 ( ).

3: Doesn't really need expanding on, but no, there is absolutely zero link to Lennart, systemd, or any other systemd developers.

4: so the reason to do blivet-gui at all, and the reason anaconda doesn't just call gparted for "partitioning" like ubiquity does, is it doesn't cover anywhere near the functionality we actually need for the Fedora (and, more to the point, RHEL) installer. gparted really is a *partitioning* tool, and there's a reason I keep referring to blivet as "storage management". It handles things that aren't just partitions. The most obvious examples are mdraid, LVM, and btrfs (insofar as btrfs acts as a volume management and redundancy system, not just as a simple filesystem like ext), but blivet has all sorts of other interesting capabilities too, primarily of interest to an enterprise audience (iSCSI, FCoE, blah blah buzzwords buzzwords). We've been interested for a while in the idea of having anaconda's GUI for actively changing disk layout be a separate process, and just having a GUI for assigning mount points within anaconda itself (or something along those lines), and this is a step towards that, as well as probably just being a useful tool for people. We can't use gparted for this purpose, because it's just not capable enough. It's really only a GUI wrapper for libparted. blivet sits on top of libparted...and also on top of btrfs-progs, cyrptsetup, device-mapper, lvm2, and mdadm (among others). It's inherently more capable and more complex. This is why we can't just "contribute" this work to gparted - they're really fairly different beasts, you can't just "contribute" blivet to gparted in much the same way you couldn't just "contribute", oh, say, the backend of emacs to the frontend of nano. It'd be a ground-up rewrite by stealth, effectively. the gparted you got out would be nothing like the gparted you started with. (to discount the humdrum technical fact that they're not written in the same language, of course.)

5: even if you consider blivet as if it wasn't one of the longest standing storage management codebases around and thus accuse it of NIH, it doesn't really work, as it just sits on top of perfectly standard tools. blivet *uses* libparted (via the pyparted wrapper). it uses e2fsprogs to create ext partitions, mdadm to create mdraid arrays, dosfstools to create FAT partitons, btrfs-progs to handle btrfs devices, lvm2 to handle LVM. it's really a logic and configuration layer on top of those tools.

(1) Never draw what you can copy. (2) Never copy what you can trace. (3) Never trace what you can cut out and paste down.