Gentoo Developers Fork udev 152
In October, Linus Torvalds expressed concerns that udev was making "...changes
that were known to be problematic, and are pure and utter stupidity." Several Gentoo developers were also concerned about the removal of features and uncooperative nature of udev maintained by the systemd developers, so they've announced a fork: "After speaking with several other Gentoo developers that share Linus'
concerns, I have decided to form a team to fork udev. Our plan is to eliminate the separate /usr requirement from our fork, among other things. We will announce the project later this week."
The project name (for now) is udev-ng, and you can grab the code from Github. Update: 11/16 21:29 GMT by U L : One of the developers commented that this isn't yet an official Gentoo project (but hopefully it will be!). There's also an informative flamewar about the fork on debian-devel.
Re: (Score:2)
If I could only get that sorted out on my laptop, I could save myself as much as five minutes a year!
Re: (Score:2)
If I could only get that sorted out on my laptop, I could save myself as much as five minutes a year!
It was a little scratched up from falling off a truck, but it was a perfectly usable spare five minutes.
Append NG (Score:2)
Stick a fork in it, it's not done.
Re:Append NG (Score:5, Interesting)
Re:Append NG (Score:4, Interesting)
I'm surprised nobody has suggested the -og suffix.
Re: (Score:1)
Can someone explain this joke? I'm feeling a big whooshing sound over my head.
Re: (Score:1)
Re:Thumbs down on the name (Score:5, Insightful)
Nice doesn't enter into it.
I owe no loyalty to crappy implementations simply because I used them before.
Lots of software wanders off the reservation from time to time and needs to be replaced, or forked back to a point in time where it was working well. If the Dev's won't listen to Linus, what other choices are there?
Re:Thumbs down on the name (Score:4, Informative)
It really does seem like theyve gone a bit crazy.... heres a snippet from a bug report [redhat.com] on the issue:
[dev gives reasons why it is impossible to probe for drivers to load prior to loading some pieces of firmware]
All that doesn't matter; do whatever you need to do, but load the firmware
async, and continue to do the rest of the job when the firmware arrives, and
do not block modprobe.
Unless Im misreading that, Kay is saying "i dont care that the thing Im asking you to do is impossible, just do i t anyways, because its more correct".
Im not a software dev, so maybe Im misreading this, but everyone seems to agree that what the udev folks are mandating is simply impossible in many instances.
not impossible, but breaks existing drivers (Score:5, Informative)
I had code in udev for a while, though it's probably been replaced now. (Moved from multithreaded to singlethreaded and made it way faster at the same time.)
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable request.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
Re: (Score:1)
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code .
There FTFY. This can never be said loudly enough. If you don't believe me, please at least believe Donald Knuth [w3.org]
I wonder where all these people got the idea that breaking software is a good idea? Apple used to (and probably still does) break backwards compatibility. However they did this; for unpublished interfaces; where they gave warnings not to use them; where they broke them regularly and where they had a reasonable alternative that worked. That is the only exception; you told people from the v
Re: (Score:2)
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet, especially if the module is actually compiled into the kernel rather than loaded later). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable position to take.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
No, this is not reasonable positions and these modules were not broken in any arguable fashion.
First, udev didn't block firmware loading until filesystems are activated. It blocked until the parent module init completes.
The case scenario happened with a dvb-c/t capture dongle. It consist of (among other things) USB multimedia controller (em28xx), demodulator that needs firmware (drx-k) and tuner connected to the demodulator (all with separate modules).
The problem is that in order to finish the initializatio
Re: (Score:2)
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable request.
It's not unreasonable at all... the module_init contract, SHOULD have said not to block. Either the contract is miswritten, or the drivers were disobeying it. Either way, it should be fixed.
And u
Re: (Score:1)
I think it's less "Do the impossible" than "Do something that doesn't really make sense just for the sake of change, and by the way, SURPRISE! We're breaking all your modules in a patch revision! Sucks to be you! Next time, maybe you'll listen to my mailing list of voices in my head!". The major problem seems to be that it's breaking everything without warning, really, for only a marginal benefit, if any.
Actually, the problem is dependency type (Score:2)
Actually, the problem is dependency type.
I'm pretty sure that Scott (keybuk) would agree that one of the major deficiencies for udev, in terms of getting this up and running as fast as possible, is that there is no disctinction between "necessary" and "sufficient".
Basically, you want to signal some conditions after an operation has completed, but that doesn't necessarily mean that you want to block operations which depend on the incomplete operation from proceeding, at least partially.
A good example for thi
Re: (Score:3)
Re: (Score:1)
"Compete on merit, not marketing"?
So? It is an "ng", next generation. So what? Next generations need not be better. Look at Windows 8. That doesn't compete on merit, but marketing.
If udev-ng is bad it won't spread fast enough. LibreOffice spread, the word.
Re: (Score:3)
From everything Ive heard, Windows 8 IS better, they just slapped an inexplicably horrendous UI on it. I havent heard any complaints from a technical perspective.
Re: (Score:2, Offtopic)
Re: (Score:3)
Re: (Score:1)
Usually, NG is an abbreviation for "No Good".
Re: (Score:3)
Although whenever I open it I do tend to tap my mouse on my monitor and say "I solemnly swear that I am up to no good".
Re: (Score:3)
In Japan. It's wasei-eigo, which means "a Japanese-made English word or phrase".
Japanese learners of English commonly make the mistake of using wasei-eigo in regular English, so they use "NG" and "go sign" and "cunning paper" expecting to be understood. Occasionally this confusion extends to English-speaking learners of Japanese, though much less often.
Re: (Score:2)
There are some evolutionary improvements to W8, although Metro seems to kill workflow. The idea of Metro apps with limited access to the filesystem, user context, and resources is a good thing.
Had MS gave an option to just have the backlevel UI and a good mechanism for Metro stuff, W8 would have been a lot more palatable, and would be able to easily compete on merit, just for the added security that having apps in their own cubbyholes provides.
Re:Thumbs down on the name (Score:4, Funny)
Re: (Score:2, Informative)
That's not a nice way to treat a project that you've used up to now. Udev isn't gone or obsolete. A fork isn't "-ng". Compete on merit, not marketing.
Being a fairly happy Gentoo user for numerous years now (posting AC to avoid the inevitable derisive sneers), that's pretty much how Gentoo's naming scheme goes. If they have a major fork of something, it'll get the -ng suffix on it until they come up with a better name (usually; sometimes the -ng name just sticks). It's not a declaration of obsolescence, it's just a naming convention.
Re: (Score:2)
Re: (Score:2)
If it can't do what needs doing, it IS obsolete and will be gone once something (like udev-ng) comes along that meets requirements.
We have not made an official announcement yet (Score:5, Informative)
I doubt anyone will listen to me at this point, but that was not an official announcement. I wrote that email to preempt a policy decision by the Gentoo Council that would have negatively affected the goals of our nascent project. A consequence of doing fully open source development is that with the exception of issues involving the security of our infrastructure, all of our internal emails are public.
Anyway, the official announcement will come later. We are still working on becoming organized. I also probably should register on slashdot.
Re: (Score:2, Insightful)
I want to thank Gentoo for not accepting this buggy piece of crap called systemd and all the unholy sh-- it depends on. It's great that there are still people left who have a good understanding how Unix(oid) is supposed to work.
Re:We have not made an official announcement yet (Score:5, Interesting)
There's plenty of us here watching from afar with large grins on our face.
Hello from FreeBSD, NetBSD, DragonflyBSD, and OpenBSD.
Re: (Score:1)
Ah, yes, does your USB hotplugging works yet?
Re: (Score:3, Informative)
Works great...we even have non-udevd based automount, with custom mount flags...does that still require hacking and a recompile?
How's pulseaudio working out for you?
Re:We have not made an official announcement yet (Score:5, Funny)
how's pulse audio working out for you?
Sorry. Could you repeat that? I can't hear a damn thing!
Re: (Score:3)
How's pulseaudio working out for you?
Touche.
Re: (Score:2)
Works fine on gentoo - they don't force you to install it, so I didn't. I'm using plain old ALSA.
Now, I can't say much other distributions.... I tried ubuntu on my laptop and sound didn't immediately work. After messing around with it, I removed ubuntu and put gentoo on (without pulse) and it worked. Yay progress!
Re: (Score:1)
Maybe Linux could use FreeBSD's devd...at least it's documented...
Re: (Score:2)
Re: (Score:2)
There's plenty of us here watching from afar with large grins on our face. Hello from FreeBSD, NetBSD, DragonflyBSD, and OpenBSD.
And some of us Linux people are happy that you are there. But it is not a good idea for you to gloat -- if Linux fails to keep the Unix legacy alive, your support base dwindles too.
Re: (Score:2)
Well, systemd is in fact packaged and working on Gentoo - in fact I use it on a Gentoo VM. Gentoo is, after all, about choice.
I see the fork as being positive in that regard - keeps everybody honest and gives the end user more choices. As long as somebody is willing to maintain it, Gentoo will accept it.
initscripts not harmful just sucky (Score:2)
In most areas I'm a bit of a unix curmudgeon but I'm happy to be rid of SysV init scripts.
And why would I like systemd?
All the reasons given here: http://0pointer.de/blog/projects/systemd.html [0pointer.de]
just call it udev (Score:4, Insightful)
Why don't you just call it udev.
I like systemd, logind, and journald. But I take serious issue with the fact that they're pulling all of these logically distinct things into the same repository. There's no difference with udev. The innovation is good, but what happened to the Unix philosophy?
Udev should never have been pulled into the same source tree. If there was a lot of code overlap, then it should have been put into a library that both udev and systemd can depend on.
So, forget the -ng. The systemd guys will probably be happy enough calling theirs "systemd-udev" or "udev-systemd"
Re: (Score:2)
I've looked into alternatives.
Wow, that was harsh even for Linus! (Score:2)
I had trouble with udev 182 and 187 myself, I had no idea they were so widespread.
So that's why my system would hang at boot (Score:5, Informative)
Yea! (Score:4, Interesting)
Well, at least there's one distro that's tired of letting Red Hat developers dictate the course of linux component development and marginalize the whole independent distro model. Hello Debian? Ubuntu? SuSE? Are you guys beginning to see a pattern here?
Re: (Score:2)
Keep in mind that this isn't a distro-wide move - I doubt the default udev will be changing anytime soon on Gentoo.
On Gentoo any dev can start an official project at any time. Gentoo is about choice. Keep in mind that with Gentoo swapping out init implementations or things like udev isn't much harder than changing desktop enviornments on most other distros. There are some using busybox mdev as an alternative to udev since things started getting tense. I've got a systemd-based Gentoo box and an openrc-ba
Re:Systemd. Still the root of all ... Stupidity (Score:5, Interesting)
Those idiots are still giving us all grief. Can't we just kick these guys and they're half-assed project to the curb? Systemd was a good idea, but shit implementation and zero admin love. Hell, they are actively admin hostile! Now they plan to Fuck up udev? great.
They didn't just plan it, they DID it.
Linus was on a roll. Read the whole thread [lkml.org]:
Stop this crazy. FIX UDEV ALREADY, DAMMIT.
Who maintains udev these days? Is it Lennart/Kai, as part of systemd?
Lennart/Kai, fix the udev regression already. Lennart was the one who
brought up kernel ABI regressions at some conference, and if you now
you have the *gall* to break udev in an incompatible manner that
requires basically impossible kernel changes for the kernel to "fix"
the udev interface, I don't know what to say.
"Two-faced lying weasel" would be the most polite thing I could say.
But it almost certainly will involve a lot of cursing.
The fact is, udev made new - and insane - rules that are simply
*invalid*. Modern udev is broken, and needs to be fixed.
Stop this idiocy.
The kernel doesn't have a lockup problem. udev does.
Yeah, that bugzilla shows the problem with Kay as a maintainer too,
not willing to own up to problems he caused.
and
So now, after you've dismissed the patch that did the equivalent fix
in udev (Ming Lei's patch basically disabled your idiotic and wrong
sequence number test for firmware loading), you say it's ok to bypass
udev entirely, because that is "more robust".
Kay, you are so full of sh*t that it's not funny. You're refusing to
acknowledge your bugs, you refuse to fix them even when a patch is
sent to you, and then you make excuses for the fact that we have to
work around *your* bugs, and say that we should have done so from the
very beginning.
Is Kay Sievers really that dumb?
Re: (Score:1)
Linus also said this, "I also call bullshit on your 'it will surely be fixed when we know
what's the right fix' excuses." This excuse pops up A LOT in bug comments of any Gnome project core component that's maintained by a Red Hat dev. In fact, it happens so much and with different RH devs that I have to question whether this attitude is mere developer arrogance or if there is something else going on. It doesn't follow that these guys are so incompetent that they'd need to keep making excuses as to why th
Re: Yes Lennart Realy is that Loony (Score:3, Insightful)
Seriousl
Re: Yes Lennart Realy is that Loony (Score:4, Insightful)
Re: Yes Lennart Realy is that Loony (Score:4, Interesting)
Don't forget Avahi -- a network-facing daemon included in the default GUI install that has a remote security hole at least once a year. And what it's for? So you can have a link-local chat (compatible only with itself) and some autodetection of rare Apple's printers.
Re: (Score:2)
Alas, it is also apparently required to get the MythTV Android remote features to work. I might consider running it but for the fact that I started using the .local domain for my internal network long before avahi came along and I really don't want to reconfigure everything.
Re: (Score:1)
avahi is also now required by cupsd :(
Re: (Score:1)
That's not fair. Pulseaudio in it's current state is the best goddamned thing that has ever happened to Linux audio. Using its unsteady beginnings to discredit Pottering is just FUD.
Having said that I totally agree on the whole systemd thing.
Re: (Score:1)
... except that it was Colin Guthrie who stepped in and essentially saved PulseAudio, not Lennart who managed to do almost anything but during his tenure.
Re: (Score:3, Informative)
I didn't save anything. I just helped out with maintenance and tried to rally the other developers already on board. Lennart's code and knowledge of the audio stuff far, far outweighs my own here. It was Lennart's dogged determination to carry on in the face of unhelpful criticism from the peanut gallery that helped get PulseAudio to its current state of relative stability - including the pushing and poking needed to get the other stuff in the stack fixed too.
Myself and other contributors (more so than me)
Re: (Score:2)
That's not fair. Pulseaudio in it's current state is the best goddamned thing that has ever happened to Linux audio.
It took what worked and made it not work, not too mention turning over a disproportionate amount of CPU time. Pulseaudio was just to get mixing to work basically because some twits decided it couldn't be done in the kernel (it can, and no one apart from OSS has tried). They broke the whole sound system for a very long time to do it. Lunacy.
Using its unsteady beginnings to discredit Pottering is just FUD.
It's not. It was unsteady because of Poettering's attitude and he simply has a big track record on whatever project he has worked on. Pulse has become sem stable down to
Re: (Score:1)
It took what worked and made it not work, not too mention turning over a disproportionate amount of CPU time. Pulseaudio was just to get mixing to work basically because some twits decided it couldn't be done in the kernel (it can, and no one apart from OSS has tried). They broke the whole sound system for a very long time to do it. Lunacy.
You're just spewing contradicting bullshit.
As you wrote, nobody but OSSv4 has ever tried to do mixing within the kernel; largely because the upstream kernel maintainers have made clear several times they won't accept it.
So, before PulseAudio, audio in Linux did not work properly. It got by and mostly worked using either hardware mixing (when those cards were common) or one of a few user space mixing solutions (esd, artds, ALSA dmix).
None of the user space mixing solutions worked quite well, so something else was needed.
Re: (Score:2)
So, before PulseAudio, audio in Linux did not work properly. It got by and mostly worked using either hardware mixing (when those cards were common)
Aaah, the golden age. I'd just get a cheapo Soundblaster and everything worked just fine. Well, except for Crossover Office/wine which would occasionally flake out and grab all the resources. That was an edge case though.
Then came the dark ages -- dmix, esd, early Pulseaudio.
Now things are pretty stable, and I'm happy with how Pulseaudio works -- especially with the seamless network sound streaming (use this surprisingly often).
Re:Systemd. Still the root of all ... Stupidity (Score:4, Interesting)
Is Kay Sievers really that dumb?
Yes and no.
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet, especially if the module is actually compiled into the kernel rather than loaded later). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable position to take.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
Re: (Score:1)
This is actually a reasonable position to take.
Why? Doesn't the system need some sort of root fs to boot? I am asking out of ignorance and curiosity, nothing else.
Re:Systemd. Still the root of all ... Stupidity (Score:4, Informative)
No, it doesn't. At boot time (specifically, at the point where execution transfers out of the boot ROM (eg. BIOS)), there just needs to be a blob of executable code at a known location in RAM.
For example, I've got a diskless system that netboots: the kernel image gets passed from the netboot server to the client RAM over a TFTP connection; the root filesystem (served over NFS) doesn't show up until a goodly chunk of the kernel has been initialized. As should be obvious, this means I can't use a network card that requires external firmware.
Re: (Score:1)
You're WRONG, there's always a rootfs in initramfs (it's mandatory since 2.6). The root dir on NFS you're talking about is the "user"'s root. The early init will switch-root to the user's one. You can always have firmware in initramfs. In fact, most embedded linux system never bother to switch-root to an "user"'s one.
Re: (Score:3)
You're WRONG, there's always a rootfs in initramfs (it's mandatory since 2.6). The root dir on NFS you're talking about is the "user"'s root. The early init will switch-root to the user's one. You can always have firmware in initramfs. In fact, most embedded linux system never bother to switch-root to an "user"'s one.
Nope, not at all.
/dev/sda5 is directly mounted as root. NFS can be used as the actual root with appropriate kernel parameters to set that up basically the same way.
The Gentoo system I'm typing this from is running 3.4.9, and does not have an initrd/initramfs. I have support for my sata controller and filesystem compiled straight into the kernel, and
@Carnildo - For a diskless system, unless very limited in memory, you're much better off making a custom initrd that contains the basic root filesystem, and
Re:Systemd. Still the root of all ... Stupidity (Score:4, Informative)
Read Linus's arguments. The issue is that apparently certain types of devices drivers that can't be initialized without loading firmware, as it is not possible for them to identify what kind of devices are present/etc otherwise. So, the system can't tell what kinds of devices to create as a result, and then nothing will ever be able to open it anyway.
In theory the idea was a good one, but in practice it didn't really work out, and simply breaking a bunch of devices with no fix possible just isn't acceptable.
Linus wasn't complaining that they should wait forever for driver authors to catch up. He was complaining that it wasn't possible for them to catch up.
Re: (Score:1)
What amazed and apalled me was what I read when LP wrote in LWN about not caring about the Unix Way.
I'm a Gentoo user and *proud* of the fact that our community has done so much to push back against the systemd elephant.
"informative flamewar" (Score:1)
"informative flamewar"
I literally LOLed.
xfree86 got kicked to curb by xorg (Score:3, Interesting)
A full-of-themselves group of developers pissed off enough people to get a viable fork going. Hopefully systemd-udev gets kicked to the curb by udev-ng.
BTW, Poettering and Sievers are the same characters who wanted a binary syslog with an undocumented format http://linux.slashdot.org/story/11/11/23/1733236/secure-syslog-replacement-proposed [slashdot.org] The Slashdot summary noted "This is being done as an extension to systemd". Sound familiar? Give them enough time, and those guys will end up rolling the linux kernel into the systemd tarball.
not an undocumented format (Score:2)
And binary logs would actually make it *much* easier for programmatic tools to parse the logs for events that they care about.
As it stands it's actually quite tricky to automatically sort through a kernel log stream looking for critical events to raise alarms over.
Re: (Score:3)
Really? Logwatch seems to do an effective job of this.
Re: (Score:1)
Huh... That's weird cuz I have stuff that parses about 150,000 syslog/sec without it being a binary format... So WTF?
When I read about journald I about shit my pants that some asshole was trying to make linux more like windows.
Re: (Score:1)
I was going to provide an example of a regex demonstrating how impossibly *easy* syslog is to parse, but /. says "use fewer junk characters."
That's not junk, it's perl dammit! :P
Re: (Score:2)
That's not junk, it's perl dammit! :P
Same thing. >_>
Zing!
Re: (Score:1)
Everything Lennart touches turns into a pile of shit. He should be the villain in a bond movie or something.
I trust the Gentoo devs (Score:2)
I completely agree with the Gentoo devs, udev is getting problematic, for starters, there are a lot of gentoo people using AUFS and squashfs to reduce the size of their /usr. Well if /usr is on a different partition, udev freaks out. It got to the point where I didnt' want to update udev but I ended up reverting my AUFS/squashfs /usr partition because of it. Can't wait to go AUFS/squashfs for /usr again!
Re: (Score:3)
Ah I see the problem, you're using AUFS ... you should be using Union Mounts since that's the one right way. The code for them will be ready real soon now ...
This is why... (Score:5, Interesting)
...I'm a (Free)BSD fanboy/fool. There is occasional stupidity (witness the recent replacement of sysinstall with some half-assed, half-baked, incomplete alternative), but usually the core team is sane, and the flamewars don't have two people both arguing from flawed foundations. The obviously *right* thing to do with this whole mess is simple: toss it.
Create a standard place for firmware files, allow it to be configured and overridden easily, make judicious use of symlinks/union mounts. Then, let the drivers do the right thing: Load up, determine if a firmware needs to be squirted in, load it if so, and continue. This idea of some entire subsystem tied to a userland daemon being responsible for loading device firmware is plain absurd. Drivers know how to load their own firmware, and with an extremely simple knob (rc.conf, linux equiv to loader.conf, sysctl, whatever) they will know where to look for it as well.
Somebody, somewhere, smoked some serious shit to come up with this udev/systemd fiasco to begin with.
Re: (Score:1)
Looks like that's the plan: Here's a preliminary patch from Linus [redhat.com], with the ability to configure it coming later on.
Re: (Score:2)
This isn't the place to argue
Are we on the same site ;)
Re: (Score:1)
I'm busy running production environments and don't have a lot of time to pay attention to the mailing lists that aren't relevant to my business. We've been humming along quite nicely on 8.x for quite some time, and I only got around to giving 9.x a first look this week. That said, if you want to get all ANGRY CAPS WARFARE, so be it.
BSDinstall is shit. I don't care how clean the code is. I don't care how many features it promises to give, someday, maybe, if someone finds the time. I *care* that the in
Systemd really that bad? (Score:1)
Case in point, nginx init script comparison (I'm going to count blank lines and such just because it doesn't really matter and w/e):
Length of the systemd script: 15 lines (http://wiki.nginx.org/FedoraSystemdServiceFile)
Length of the init.d script (for ubuntu): ~300 (http://wiki.nginx.org/Nginx-init-ubuntu)
I use this example as I recently ran into needing to manually create this service file and make a couple modifications for my setup. This was thankfully stupidly easy thanks to systemd. Oh, and my server
Re: (Score:1)
Really? It's one line on FreeBSD, why do Linux admins want to work so hard?
Re: (Score:2, Insightful)
Answered with no evidence (or even really an example) to support your claim? Oh internets. How exactly, as in practical terms, have they 'branched out too far'? I don't think its perfect by a long stretch but there are serious practical gains to using systemd for servers that require custom configuration and can't rely on stock implementations, saves me time so I guess I'm happy with that.
Re: (Score:2)
Ahh, so what you really want is the BSD rc subsystem or perhaps rcng in Gentoo
Or maybe launchd, which was one of the inspirations from systemd [0pointer.de], but has 25022 lines of source code (as per a recent download of a source tarball of the 10.8.2 version [apple.com]) rather than 158743 lines (as per a recent checkout with git clone git://anongit.freedesktop.org/systemd/systemd), with "lines of source code" determined by finding all source files (files matching any of *.[chylsSxm], *.ch, *.fth, *.sh, *.m[td], *.asm, *.java, *.jav, *.cpp, *.cc, *.cxx, *.cp) and xargsing them through wc -l.
No, launchd pro
Arch Linux switched to systemd (Score:3)
And anyone who doubts the wisdom of the move to systemd on the Arch Linux forums gets roasted by the maintainers. Arch Linux maintainers get hostile, and defensive and unbending very quickly. Not attitudes that inspires confidence.
The switch has not been smooth. Documentation is lacking. The latest thing was that a routine update removed the shutdown option from the GUI menu. I've also noticed that journalctl (the replacement for "less /var/log/messages") is slow when one wants to view more of the recent history than journalctl shows with the -f flag. I'm thinking systemd compresses the logs almost right away, then journalctl must uncompress everything from the beginning each time the admin wants to view the latest logs. If so, it doesn't speak well of the systemd developers' ability, to have designed software to proceed in such an inefficient manner.
Re: (Score:3)
I'm afraid Arch is dying. I used to love it back when it made sense but they've abandoned what made Arch great. They killed their own installer, moved to systemd by default and are still huge gnome3-shell fanboys despite all the backlash on it.
Its a shame, Arch has/had some of the best documentation out there. It's also the most up-to-date distro out there which I really appreciated. I'll miss Arch and hope they go to a more sane system soon.
Re: (Score:1)
Uh-Oh. Time to look into that, and how to avoid that. But as far as I can see the change so far only affects the default choice on the new install media, so I hope there is still at least a 1-2 years period in which we see if the whole thing straightens itself out or if it goes up in flames. Especially since it seems to be completely contrary to the "KISS" principle for which I choose ARCH. (For home use and a few dozen service boxes at work)
For example one points from the systemd Wiki page:
Service startup
Re: (Score:2)
The problem with Arch is that it got too popular, and the forums got overrun by people who wanted to be spoon fed. The devs got sick of being friendly and nice to people, and the more ignorant of the newbies who stuck around turned into something like Gentoo ricers [funroll-loops.info] (note: I like Gentoo, and it's users, some very knowledgeable people on the mailing lists and forums). These days the Arch forums can get pretty hostile if you criticise Arch in any way, but it's because of the bar
Great plan by udev/systemd (Score:5, Insightful)
This whole idiocy is intended to force modules devs to actualy do nothing during init so that udev/systemd can advertise faster boot up times.
Re: (Score:3, Informative)
Re: (Score:3)
3. it's basic design is an attempt to create a solution to an NP complete problem.
Which is?
Re: (Score:1)
Re: (Score:2)
So you're upset about wasting almost 1MB of space on your multi-terabyte hard drive in order to work around stupid disk manufacturer tricks like lying about their real block size? There's even less reason to complain on an SSD because that almost 1MB will never be written to and hence can be recycled for wear leveling.
I can understand the the issue with dd of a disk image, but copying an old disk image and then deleting and recreating the partitions is a pretty unusual use case compared to installing fresh