Poettering: Rethinking PID 1
Now, if that's all they are waiting for, if we manage to make those sockets available for connection earlier and only actually wait for that instead of the full daemon start-up, then we can speed up the entire boot and start more processes in parallel. So, how can we do that? Actually quite easily in Unix-like systems: we can create the listening sockets before we actually start the daemon, and then just pass the socket during exec() to it. That way, we can create all sockets for all daemons in one step in the init system, and then in a second step run all daemons at once. If a service needs another, and it is not fully started up, that's completely OK: what will happen is that the connection is queued in the providing service and the client will potentially block on that single request. But only that one client will block and only on that one request." The whole thing is an interesting discussion of how system initialization should work.
Upstart maintainer Scott James Remnant has posted a response to the
announcement. "So it's great to see some Fedora and OpenSuSE guys
working on this too, and bringing some different ideas to the
table!
"
Posted Apr 30, 2010 14:00 UTC (Fri)
by pranith (subscriber, #53092)
[Link] (4 responses)
Posted Apr 30, 2010 15:06 UTC (Fri)
by ThinkRob (guest, #64513)
[Link] (2 responses)
And as far as "ripping off" FreeBSD, I disagree with that claim. They use BSD-licensed code in a manner compliant with the BSD license. That's not ripping off -- that's using the code in the manner in which the authors intended.
Posted Apr 30, 2010 19:08 UTC (Fri)
by efexis (guest, #26355)
[Link] (1 responses)
(*excuse the terrible programmer pun!)
Posted May 2, 2010 18:07 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
Please consider that there is only so ->||<- much real innovation a given group of people can come up with in a reasonable timeframe. Sure, everybody toots their "innovation", how "this year's car is completely different from last year's"... While under the hood they have the same engine, the same steering system, and so on. The only real change is cosmetical (or replacing last year's radio by another model).
Posted May 4, 2010 8:22 UTC (Tue)
by k8to (guest, #15413)
[Link]
There's some good ideas in there, but the implementation leaves something to be desired.
Posted Apr 30, 2010 15:10 UTC (Fri)
by cyperpunks (subscriber, #39406)
[Link] (22 responses)
Posted Apr 30, 2010 15:15 UTC (Fri)
by sharms (guest, #57357)
[Link] (15 responses)
Where does your sense of entitlement come from?
Posted Apr 30, 2010 15:31 UTC (Fri)
by DOT (subscriber, #58786)
[Link] (13 responses)
</sarcasm>
Posted Apr 30, 2010 15:56 UTC (Fri)
by DOT (subscriber, #58786)
[Link] (12 responses)
But when you speak of "entitlement", all I hear is "ignoring all sense of responsibility". And that's not exactly a virtue of open source, what with all the dead projects in the Linux audio mess alone. PA has been the project to end all that madness.
Posted May 1, 2010 16:04 UTC (Sat)
by sturmflut (subscriber, #38256)
[Link] (11 responses)
That's a joke, right? I've never seen PulseAudio working out of the box on any machine, it's usually the first package I remove after installation.
There is no "Linux Audio Madness", ALSA and the multimedia libraries have done a good job already long before Poettering even started working on PulseAudio.
Posted May 2, 2010 0:32 UTC (Sun)
by bronson (subscriber, #4806)
[Link] (10 responses)
That's comedy. It's called selection bias.
PulseAudio is working great for the vast majority of people on all current Linux distros. If you're one of the few people who's running a distro less than a year old and still seeing issues, I suggest filing some bugs.
Posted May 3, 2010 1:46 UTC (Mon)
by waucka (guest, #63097)
[Link] (9 responses)
Personally, I find that I need to install PulseAudio in order to make things work on my Kubuntu machines. I don't think I've had any sound-related problem in the past year that was caused by PulseAudio itself.
Posted May 3, 2010 11:31 UTC (Mon)
by paulj (subscriber, #341)
[Link] (1 responses)
As per a previous comment, "perfect is the enemy of good". A perfect but complex solution that has strange edge-cases and failure modes may be worse than a simpler solution that, though not being as auto-magic, consistently behaves in a way the user can understand.
KISS.
Posted May 11, 2010 23:57 UTC (Tue)
by obi (guest, #5784)
[Link]
For example, I don't know about you, but I never managed to find a consistent "rule" on how to set my volume with max amplification without any clipping. Or to record analog with optimum levels. Do I set PCM to max, DRC range to 50%, Master to 70%, flip the gain switch? And it's different on every machine I own to boot.
Pulse with working alsa drivers is heaven. It's the first application that tries to do it right, so it's normal that all the underlying driver bugs are exposed too. If driver features haven't been used until now, they're by definition untested.
Posted May 5, 2010 14:23 UTC (Wed)
by alankila (guest, #47141)
[Link] (6 responses)
Posted May 5, 2010 14:45 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (3 responses)
The trouble with that is that cheap hardware (the sort that often lies about dB levels) also tends to have poor quality analogue amplifiers, such that running at maximum volume gets you lots of audible noise. You therefore have to face a nasty conundrum: on the one hand, you want to keep the analogue volume as low as possible, to keep the analogue noise below the threshold of hearing. On the other hand, you need it high enough to get the volume level the user has requested.
This all leads to pain - PulseAudio's solution is as good as you're going to get, and once the bugs are out of ALSA, it'll work fine. In the meantime, bugsquashing needs to be done :(
Posted May 7, 2010 1:06 UTC (Fri)
by alankila (guest, #47141)
[Link] (2 responses)
I had personally some annoyance with pulse's tendency to force a particular mixer state each time it started, and unfortunately it disabled digital output for applications that did not talk through pulse, and thus I lost sound for a number of applications.
Posted May 7, 2010 7:18 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (1 responses)
This "optimal" setting you talk about doesn't exist. On my el-cheapo card, I want it to be consistently as low as possible without being so low that I can't reach the volume I want. This means about 25% for normal desktop sounds, about 30% when playing games, and about 50% when playing movies.
With Pulse's auto-adjusting going on, this Just Works. Without the auto-adjust, I would constantly be playing with the volume controls to make it happen.
Posted May 7, 2010 14:09 UTC (Fri)
by alankila (guest, #47141)
[Link]
Still, in the future new drivers will probably be tested with the pulse's requirements in mind and thus all the pain is temporary, right?
Posted May 6, 2010 1:43 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
Posted May 7, 2010 1:01 UTC (Fri)
by alankila (guest, #47141)
[Link]
Posted Apr 30, 2010 16:19 UTC (Fri)
by paulj (subscriber, #341)
[Link]
Posted Apr 30, 2010 15:23 UTC (Fri)
by tao (subscriber, #17563)
[Link]
Posted Apr 30, 2010 16:38 UTC (Fri)
by Trelane (subscriber, #56877)
[Link] (1 responses)
"Is this a Red Hat project?
It strikes me that this implies that his day job is PA (a posting on the other recent pulse thread here on LWN said as much, offering it as an explanation of why Linux is the premiere platform for PA) and he hacks on systemd on the side.
Posted May 1, 2010 21:55 UTC (Sat)
by Sho (guest, #8956)
[Link]
Posted Apr 30, 2010 19:37 UTC (Fri)
by efexis (guest, #26355)
[Link]
Posted May 6, 2010 1:41 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
And anyway, since when do you get to complain how my work priorities are set?
Posted May 6, 2010 7:28 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Apr 30, 2010 15:25 UTC (Fri)
by jwb (guest, #15467)
[Link] (32 responses)
Posted Apr 30, 2010 15:35 UTC (Fri)
by ovitters (guest, #27950)
[Link]
Also, you can always switch to another interface (Windows, Mac OS X, etc). You do not "have to endure".
Posted Apr 30, 2010 16:32 UTC (Fri)
by Kit (guest, #55925)
[Link] (7 responses)
Posted Apr 30, 2010 16:39 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (6 responses)
I can think of another example: if you have no printers plugged in, and never configured any network printer, there is no real need to start cupsd up. But if you plug in a USB printer, it should start.
Posted Apr 30, 2010 17:39 UTC (Fri)
by hadess (subscriber, #24252)
[Link]
Well, that's already what bluetoothd does, if you have a distro with a clue.
Posted Apr 30, 2010 20:03 UTC (Fri)
by jwb (guest, #15467)
[Link] (4 responses)
Posted May 1, 2010 2:08 UTC (Sat)
by zlynx (guest, #2285)
[Link] (2 responses)
But I know from personal experience, those unused daemons will have all their allocated RAM swapped out into tiny 4K pieces that will take 10-20 seconds for a laptop drive to re-collect.
It's much faster to start the daemon from scratch than to swap it in.
Posted May 6, 2010 2:51 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted May 6, 2010 15:58 UTC (Thu)
by zlynx (guest, #2285)
[Link]
Posted May 1, 2010 8:26 UTC (Sat)
by xav (guest, #18536)
[Link]
Posted Apr 30, 2010 20:29 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (21 responses)
1. Start fewer processes and only start them when they're actually needed.
2. Minimize boot time. This is very important for server admins trying to get to "five nines" of uptime. Sometimes you are upgrading your kernel or hardware, and you just have to reboot. It needs to be quick.
3. Manage the processes on the system. For example, put the updatedb process in its own appropriately configured cgroup. This should limit how much I/O and CPU updatedb can grab from foreground tasks.
4. Handle dynamically changing hardware configurations properly. For example, start the correct daemons when a bluetooth device is plugged in.
A lot of the "quirky interfaces" people complain about are things like automounting USB thumb drives not working correctly, or bluetooth setup. These are things that systemd is explicitly designed to address.
Posted Apr 30, 2010 21:24 UTC (Fri)
by intgr (subscriber, #39733)
[Link] (1 responses)
Unfortunately for servers, any boot process optimization is completely irrelevant because the proprietary BIOS and SAS controller take a whole 5 minutes to initialize. It's a little ironic that the cheapest desktop computer can be up and running in 30 seconds, but the more expensive your server, the slower is your boot time.
Posted Apr 30, 2010 21:45 UTC (Fri)
by jengelh (guest, #33263)
[Link]
Oh it's a good tradeoff. Given enough cores - and SGI has done these experiments - the firmware will be faster enough than the Linux kernel bootup. :-) IIRC it was something like.. 12 minutes for 4096 cores?
Posted May 1, 2010 2:25 UTC (Sat)
by pabs (subscriber, #43278)
[Link] (18 responses)
Posted May 2, 2010 23:24 UTC (Sun)
by jwb (guest, #15467)
[Link] (2 responses)
Posted May 3, 2010 15:11 UTC (Mon)
by bronson (subscriber, #4806)
[Link] (1 responses)
I don't see a big race... If you're talking about missing changes because they occurred before the treewalk is done then I agree: inotify needs to be established before the system starts doing much.
Personally, I remove locate and updatedb from all machines I manage, including laptops. I find that all my needs are met by dpkg --search and the find command. I'm really surprised that updatedb is still a part of default Linux installs: it's intrusive and locate is almost useless!
Posted May 6, 2010 16:24 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Intrusive yes, but so useful and convenient.
locate answers instantly, and there is no need to remember it's command line syntax (it has none). Sometimes I use locate instead of find even when I know for sure that the file is just a few directory levels below.
Posted May 3, 2010 22:18 UTC (Mon)
by cmccabe (guest, #60281)
[Link] (9 responses)
My point was that you often want to do large jobs in the background, without having them interfere with what's going on in the foreground. Putting them in a separate cgroup is a step forward.
Beagle acts like a filesystem index, and listens to inotify. The last time I tried it, it made my system unusably slow by aggressively trying to index files as soon as they were created. That was on an older computer with only one core, though. Maybe I'll give it another try in the future when I get some time. In the meantime, asserting that alternative solutions "should not exist" seems kind of trollish.
Posted May 7, 2010 7:57 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (8 responses)
Posted May 16, 2010 23:53 UTC (Sun)
by cmccabe (guest, #60281)
[Link] (7 responses)
Oh, ok.
I always forget where things are, so I end up using slocate all the time.
It seems like are some tradeoffs here. Having a daemon that listens to inotify makes things slower while you're using the machine. It's more complicated and more likely to lose track of files. The updatedb / slocate scheme probably uses more power in total because it does a treewalk while you're asleep. But it is simple and always works. Of course, information may be slightly out-of-date.
Maybe people who are really concerned about the power issues should do updatedb once a week instead of daily? Would that be an acceptable tradeoff?
I suspect that, like vi/emacs, this debate will not be resolved any time soon.
Posted May 17, 2010 5:51 UTC (Mon)
by avik (guest, #704)
[Link] (6 responses)
In short, it's a static solution that doesn't fit the dynamic environment of the last 15 years.
Posted May 17, 2010 6:31 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted May 17, 2010 9:57 UTC (Mon)
by nye (subscriber, #51576)
[Link]
>They must be easy to back up, with properties like that.
Arg. This is how user files work in Windows by default. So annoying. Windows makes a chore out of things that should be so simple.
Anyway the solution is probably to have backups done individually by the user if there is only one and it's the same person as root (ie. yourself), or to have a user whose dedicated role is to be able to read every non-special file for backup purposes, without any of the other permissions root would have which could potentially be dangerous. Then again, you could just run updatedb as that user, so...
Posted May 17, 2010 6:49 UTC (Mon)
by dlang (guest, #313)
[Link] (3 responses)
Posted May 17, 2010 7:56 UTC (Mon)
by avik (guest, #704)
[Link] (2 responses)
(nor am I assuming everyone uses systems like mine; it's sufficient that a substantial fraction of users suspend or turn off their machines at night, or use detachable storage, to show that updatedb is outdated)
Posted May 17, 2010 10:25 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
Posted May 17, 2010 11:04 UTC (Mon)
by avik (guest, #704)
[Link]
Posted May 7, 2010 7:55 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted May 8, 2010 22:08 UTC (Sat)
by nix (subscriber, #2304)
[Link] (3 responses)
(if the inotify daemon did exist, it would need to be able to be told to write out separate dbs for specific subtrees, at least, so that the NFS server could run it and export locate databases to its clients.)
Posted May 8, 2010 22:34 UTC (Sat)
by foom (subscriber, #14868)
[Link] (2 responses)
Posted May 9, 2010 9:53 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
No thank you.
Posted May 10, 2010 1:35 UTC (Mon)
by foom (subscriber, #14868)
[Link]
And security shouldn't be a huge deal -- you only need expose it to the users you're exporting the filesystem to, anyhow.
Posted May 1, 2010 17:16 UTC (Sat)
by Lukehasnoname (guest, #65152)
[Link]
Posted Apr 30, 2010 15:59 UTC (Fri)
by foom (subscriber, #14868)
[Link]
Posted Apr 30, 2010 16:13 UTC (Fri)
by martinfick (subscriber, #4455)
[Link] (5 responses)
I cannot help but wonder whether this could be extended to become "cluster aware" and replace (or integrate with) the heartbeat project. The configuration of this systems sounds much simpler and more elegant than the nasty XML nightmare of heartbeat's config. It sounds a lot like the systemd templating system could replace or perform the role of OCF scripts? (OCF scripts are similar to sysV scripts but with parameters).
How exciting to think that someday maybe the same system could start local services and cluster aware services. Lennart, have you given any thought to ways to add cluster dependencies to systemd? If you get this right early, it might be a lot easier than after systemd adoption (if it does take off)!
Posted Apr 30, 2010 16:32 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (1 responses)
I do not know if he is looking at the comments here. You should post this as a comment on Lennart's blog.
Posted May 1, 2010 9:46 UTC (Sat)
by Zenith (guest, #24899)
[Link]
But that does not imply that he will see/read every comment, so your advice is still sound.
Posted May 2, 2010 14:03 UTC (Sun)
by niner (subscriber, #26151)
[Link]
Posted May 6, 2010 1:48 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
Lennart
Posted May 6, 2010 3:48 UTC (Thu)
by martinfick (subscriber, #4455)
[Link]
http://www.linux-ha.org/wiki/Heartbeat
In other words it starts/stops services (resources) across machines instead of just on one machine. It also often needs to take into account dependencies between resources, say: mount the local FS to be exported before starting the NFS server, or mount an NFS share before serving it up from (and thus starting) apache.
But now if you wanted to enhance a basic setup so that 2 different hosts could run apache and serve up that same NFS share (for failover/high availability reasons), and you only ever wanted one apache instance to run at once (since it might use the same IP), today's init systems cannot handle this, but why not? This second enhanced setup is not really a great conceptual leap from the first (even if it is a great technical leap).
So instead, to support such a setup, the apache start/stop script has to be managed by some other daemon which coordinates with other hosts. This is how heartbeat got started, and eventually it evolved to do more complex stuff (some of it similar to systemd's templates). But this is not ideal because now we have two different "event" systems managing resources/services and they are not aware of each other and moving resources between the two systems can be hard and error prone. A simple config change in one system would be nicer than moving the management of a simple resource between systems (likely for the same reason that you feel that some time based events should be managed by systemd instead of cron).
There really is a lot of overlap between the two ideas (heartbeat and systemd): both start/stop resources ordered by dependencies, both can monitor the status of those resources, both can respond to events, both can simplify the management of multiple like resources by sharing common configuration aspects between them. The only conceptual difference between the two systems is that systemd attempts to manage resources on one single machine and heartbeat manages them across many machines (cluster-wide).
I hope that you will take some time to consider the problems of managing services/resources across machines and see if you don't agree that a system such as yours would be a good/logical place to address this problem. If you are going to redesign service management, it would be a shame to not take the opportunity to see if you can't unify local/cluster resource management. After all, the future does likely lie in the cloud. Thanks!
Posted Apr 30, 2010 16:35 UTC (Fri)
by Trelane (subscriber, #56877)
[Link] (6 responses)
Is there a good argument for replacing cron, aside from killing Yet Another Daemon?
Posted Apr 30, 2010 16:40 UTC (Fri)
by Trelane (subscriber, #56877)
[Link]
"timer shall provide functionality similar to cron, i.e. starts services based on time events, the focus being both monotonic clock and wall-clock/calendar events. (i.e. "start this 5h after it last ran" as well as "start this every monday 5 am")"
The answer seems to be that it allows more complicated run conditions, although cron could be extended to support such timer-based things. Are there other consequences?
Posted May 6, 2010 1:54 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (4 responses)
And secondly cron works by waking up every minute and checking all jobs whose time is come. Ugly. It would be better if it would sleep and only wake up when the next job is actually read to be run.
Posted May 6, 2010 10:19 UTC (Thu)
by hppnq (guest, #14462)
[Link] (2 responses)
That's exactly the purpose. Cleverer schedulers would need a timeout to detect a runaway job, and it is not at all clear what should happen when the job times out. Better to let the jobs handle this, as indeed, most probably do.
Posted May 6, 2010 21:32 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
And the problem of runaway jobs is orthogonal to this, as it applies to every job you run in the system. And we already provide the right tools to deal with this (i.e. timeouts, yadda yadda)
Posted May 7, 2010 17:47 UTC (Fri)
by hppnq (guest, #14462)
[Link]
Posted May 8, 2010 22:56 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted May 1, 2010 8:56 UTC (Sat)
by aleXXX (subscriber, #2742)
[Link] (25 responses)
Seriously ?
Can't we just have our system-level software stabilize again for some time ?
Like, not implementing a new system level solution, and once it starts to mature, replace with a new even cooler one ?
(HAL, DeviceKit, PolicyKit, PA, ...)
I have the feeling that a typical Linux system is getting more and more like a black box :-/
Alex
Posted May 1, 2010 12:10 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (19 responses)
Oh, and about systemd: Poettering says that Upstart's design is flawed, and he makes some good points. It doesn't make sense to replace the sysvinit suckage with upstart suckage when your goal is to make something that doesn't suck.
Posted May 1, 2010 16:17 UTC (Sat)
by sturmflut (subscriber, #38256)
[Link] (18 responses)
Oh, sure. Let's ignore Desktop Effects, KDE Plasma, Desktop Search, Gallium3D and friends. An Audio Server which still regularly blocks audio and has features 90% of the users don't need is certainly much better than all of that.
PulseAudio is the package which I immediately drop after any installation.
Posted May 1, 2010 16:43 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (4 responses)
So the only thing from your list that might actually be useful is desktop search engines, and i personally don't use those as well, so they're definitely way behind pulseaudio (which i use every day) on my personal awesomeness list.
Posted May 5, 2010 10:00 UTC (Wed)
by nye (subscriber, #51576)
[Link] (3 responses)
All it ever seems to do is break things and add latency, with utterly no benefit. Even if it were eventually fixed, it would still not be worth using, because it is a layer that adds *no value*. There is no way to do PulseAudio right, because it is by its nature the Wrong Thing. It is the project that never needed to exist. It serves no purpose. Pathetic acts for a worthless cause.
To rub nitric acid into the wound, every time somebody points out something that it breaks, the blame is shifted elsewhere. 'I know it worked before, but it's ALSA's fault'; 'I know it worked before, but you shouldn't use Flash'; 'I know it worked before, but you should sponsor an open source clone of World of Warcraft'. My response is this: if the system was working before PA, and is not working now, THEN IT IS PA'S FAULT MOTHERFUCKER.
Anyway, this kind of mindless heatseeking with no care for what gets broken in the pursuit of shinies is why I stopped using Linux on my desktop last year. Fortunately, even if Lennart gets his grubby mitts into init, I don't see Debian following that sort of destructive upheaval any time soon.
Posted May 5, 2010 14:27 UTC (Wed)
by pixelpapst (guest, #55301)
[Link]
Posted May 6, 2010 16:02 UTC (Thu)
by Spudd86 (guest, #51683)
[Link] (1 responses)
Flash was fixed...
Almost every alsa app has been fixed
about the only thing that's still sketchy is oss emulation, but that has NEVER been very good (yea it used to work but you had close everything you had running that was using sound... now you can at least use pasuspender and pulse will let the sound card go so your oss app can run... and you don't even have to kill your browser because flash refuses to let go of the sound card)
All those ALSA apps that were broken with pulse were ALSO broken for lots of real hardware (like say usb audio, or bluetooth, bluetooth since it essentially works the same way pulse does... userspace emulation, usb since it's not on a PCI bus and so it works differently from a sound card and breaks a lot of the same assumptions that pulse does)
pulse does add value, MASSIVE amounts of value, for starters I have far FEWER problems with audio now than I did before pulse (see flash...)
Now either go make something that sucks less than pulse or shut up
Posted May 6, 2010 16:41 UTC (Thu)
by nye (subscriber, #51576)
[Link]
Without PA, some given application works.
Thus, any claim that PA is not at fault is at best retarded, and at worst outright deception.
>Now either go make something that sucks less than pulse or shut up
Okay, here is an example of something that sucks less than Pulse:
EOF
Posted May 3, 2010 6:47 UTC (Mon)
by bni (guest, #27103)
[Link] (12 responses)
Before it applications would hang when trying to access the audio device if it was already taken by say, XMMS. You would constantly have to micromanage and pay attention to wich applications wanted to play sound.
That someone could long back to those days, simply cant understand it.
Posted May 3, 2010 12:37 UTC (Mon)
by liljencrantz (guest, #28458)
[Link] (11 responses)
Posted May 5, 2010 4:51 UTC (Wed)
by k8to (guest, #15413)
[Link] (7 responses)
Posted May 5, 2010 9:47 UTC (Wed)
by nye (subscriber, #51576)
[Link] (6 responses)
Do you have any actual experience of that with a device made in the last 10 years?
I spent £20 in 2001 on a device that did. It was the cheapest sound device I could find at the time.
How do you define 'less expensive'?
Posted May 5, 2010 14:45 UTC (Wed)
by k8to (guest, #15413)
[Link] (4 responses)
The current one is IHC8 based: details:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
This was purchased in 2007, I believe.
Posted May 5, 2010 16:26 UTC (Wed)
by nye (subscriber, #51576)
[Link] (3 responses)
The fact remains that ALSA has always Just Worked with every sound device I've thrown at it[0]; perhaps it's been using some kind of software mixing for the last hardware generation or two. I neither know nor care.
[0] That's not to say that everythings alwys been *perfect* - somewhere around the 2005 era I did experience quite a lot of crackling with the default configuration when playing WoW, which wasn't there when using OSS, and required increasing the buffer size.
Posted May 6, 2010 3:13 UTC (Thu)
by k8to (guest, #15413)
[Link] (2 responses)
Of course, a large number of programs use OSS, where it just doesn't feel like doing software mixing. Because it's too le hard.
Then your sound device gets locked exclusively.
Posted May 6, 2010 16:06 UTC (Thu)
by Spudd86 (guest, #51683)
[Link] (1 responses)
Posted May 6, 2010 19:04 UTC (Thu)
by k8to (guest, #15413)
[Link]
Posted May 6, 2010 16:03 UTC (Thu)
by Spudd86 (guest, #51683)
[Link]
Posted May 6, 2010 2:04 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
All newer designs don't support hardware mixing anymore (i.e. AC97, HDA). In fact hardware mixing was available in audio hardware only in a short time at the beginning of the 2000's, and only on a few sound cards targeted for the let's say "premium" market. CPU vector extensions such as SSE made that obsolete. Mixing is best done in software these days.
Forget about hardware mixing already.
Posted May 8, 2010 22:58 UTC (Sat)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Apr 7, 2012 0:29 UTC (Sat)
by scientes (guest, #83068)
[Link]
and this card was totally broken in the early days of pulseaudio (I havn't tried to use it since, but I never did have pulseaudio working on that card.)
Posted May 1, 2010 15:24 UTC (Sat)
by AndreE (guest, #60148)
[Link] (1 responses)
Posted May 5, 2010 14:29 UTC (Wed)
by pixelpapst (guest, #55301)
[Link]
Posted May 6, 2010 1:58 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
Back in the old days everything was better, wasn't it?
If you are this conservative and not interested in any progress you are welcome to just stick to whatever your distro is now at. After all its all free software, you can do with it what you want. Nobody forces you to upgrade to the latest and greatest if you don't want to.
Posted May 6, 2010 19:33 UTC (Thu)
by aleXXX (subscriber, #2742)
[Link]
I mean, having a replacement for init, ok.
Ok, slightly exaggerated...
Alex
Posted May 9, 2010 19:54 UTC (Sun)
by Tet (guest, #5433)
[Link]
Personally, I've had far more problems with upstart screwing up my boxen than I've had with pulseaudio. That's not to say pulseaudio is free from problems -- far from it. I still have applications preventing other apps from making noise, and that situation stays until the problematic app is killed. And volume control is an impenetrable mess now. But by and large, pulseaudio works. I can't say the same for upstart.
I have the feeling that a typical Linux system is getting more and more like a black box
Sadly, I agree with that 100%. There is far too much going on behind the scenes on a modern Linux distribution, and seemingly little way to find out what, short of reading the code. We're in serious need of some improved documentation.
Posted May 3, 2010 15:43 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (32 responses)
Posted May 3, 2010 19:11 UTC (Mon)
by nescafe (subscriber, #45063)
[Link] (13 responses)
Posted May 3, 2010 19:20 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (12 responses)
Posted May 3, 2010 20:20 UTC (Mon)
by nescafe (subscriber, #45063)
[Link] (11 responses)
People do things like
for foo in 'find /path -name someglob'
over several thousand files and then complain about how slow shell code is.
Seriously.
Posted May 3, 2010 21:00 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted May 6, 2010 12:27 UTC (Thu)
by nescafe (subscriber, #45063)
[Link]
Posted May 10, 2010 17:36 UTC (Mon)
by jschrod (subscriber, #1646)
[Link]
Posted May 5, 2010 13:54 UTC (Wed)
by paulj (subscriber, #341)
[Link] (7 responses)
You'd be much better off with:
E.g. Your shell example could be done with:
or using GNU find's built-in xargs-ish feature (when was that added?):
This is meant more for the peanut gallery than for you ;) - I was expecting there'd be a rush to offer more optimal one-liners, strangely there hasn't been. ;)
1. Though, as Padraig Brady has shown me, beyond a certain size of file, there is a benefit to using grep to pre-filter input if you're discarding a sufficient amount of that input, as grep is much faster at processing each line than AWK.
Posted May 5, 2010 14:05 UTC (Wed)
by johill (subscriber, #25196)
[Link] (1 responses)
sed 's/foo/\0/;t;d'
Posted May 5, 2010 16:30 UTC (Wed)
by martinfick (subscriber, #4455)
[Link]
Posted May 5, 2010 14:46 UTC (Wed)
by k8to (guest, #15413)
[Link] (1 responses)
Posted May 5, 2010 15:07 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted May 5, 2010 16:28 UTC (Wed)
by fredi@lwn (subscriber, #65912)
[Link] (2 responses)
find | grep | xargs cut ...
or similar. Though the -exec on your last example for what i recall is slower than:
find /foo -name $GLOB -print0 | xargs -0 SOMECOMMAND
That because with -exec you start on each found entry another process while xargs passes all entriess to the same process if they fit in the command line max length. Hope i gave the idea & sorry for my bad english.
Posted May 5, 2010 18:05 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted May 6, 2010 15:48 UTC (Thu)
by fredi@lwn (subscriber, #65912)
[Link]
Posted May 4, 2010 14:50 UTC (Tue)
by RCL (guest, #63264)
[Link] (16 responses)
Posted May 4, 2010 15:48 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (15 responses)
Posted May 5, 2010 4:55 UTC (Wed)
by k8to (guest, #15413)
[Link] (14 responses)
For you, I'm sure that's true.
I rather think bourne is more well spoken on *UNIX* systems than lua or scheme.
Yeah, shell is a lousy language. It's really only good for like.. starting up programs. Oh wait.
Posted May 5, 2010 10:29 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (13 responses)
Posted May 5, 2010 13:16 UTC (Wed)
by paulj (subscriber, #341)
[Link] (9 responses)
Posted May 5, 2010 14:28 UTC (Wed)
by nye (subscriber, #51576)
[Link] (6 responses)
Shell syntax is unique, and not in a good way. Writing shell scripts is *hard*, and *nasty* unless you do it all day, every day. It's nothing like any other language you might use, and there are innumerable gotchas that can be hard to spot. The result is that, more so than most languages, shell scripts tend to be written using largely a mixture of copy/paste cargo-culting, and experimentation until it seems to work for you.
[The last time I wrote a shell script I was bitten by the fact that I *still* can never remember when I should be doubling up square brackets, or when I'm supposed to use whitespace within them or not, plus the fact that the exclamation mark can be used as negation in some places, but in others will expand to the previous command. At least I've now internalised the knowledge that zero evaluates to true, bizarrely, but it still makes test expressions harder to read. Lets not even go into the weird way in which arguments are passed around.]
Posted May 5, 2010 15:42 UTC (Wed)
by paulj (subscriber, #341)
[Link] (2 responses)
Judging by Lennart's blog though, he does not intend to get rid of shell. Rather he wants to move common functionality out of the myriad shell scripts and up into the init system. Potentially leaving just a per-service configuration file to be filled in (for many services anyway)...
Posted May 5, 2010 22:12 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted May 6, 2010 2:12 UTC (Thu)
by AndreE (guest, #60148)
[Link]
Posted May 6, 2010 12:39 UTC (Thu)
by nescafe (subscriber, #45063)
[Link] (2 responses)
If your shell script starts with #!/bin/bash or #!/bin/ksh93, you should use [[ ]] syntax -- it is in general faster and more flexible than the test command (which is what you are actually using when you use single square brackets).
If there is any doubt, read the fine man page for the shell you are targeting. The bash man page is quite thorough -- I recommend having it open as a reference when coding in bash.
Posted May 6, 2010 15:41 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
Still don't know what the difference is though. The bash manual is not especially enlightening in this area (NB. if I really cared I would Google it, of course)
>If there is any doubt, read the fine man page for the shell you are targeting. The bash man page is quite thorough -- I recommend having it open as a reference when coding in bash.
Thorough, no doubt. Not especially useful however - unless you know precisely what to search for, finding a needle in that haystack is almost never worth the time when Google is available. The dash manpage is slightly less unwieldy, as one might expect.
Still, this seems to prove the point rather well - what other languages require you to keep the documentation open constantly due to unintuitive and inconsistent choices in basic syntax?
I'm not saying that shell scripting is absolutely intolerably awful, just that it tends to make easy things hard. For scripts that don't need specific features like setting traps or atomic lockfile creation, it's much less painful to use, say, Lua. Or Python if speed is of no account.
Posted May 6, 2010 17:12 UTC (Thu)
by nescafe (subscriber, #45063)
[Link]
>Still don't know what the difference is though. The bash manual is not especially enlightening in this area (NB. if I really cared I would Google it, of course)
[[ ]] is syntax, [ ] and test are (builtin) commands. [[ ]] does not perform word splitting or pathname expansion on its arguments (no more quoting "just because", and you can use bash's builtin regex support (and get rid alot of trivial uses of sed and awk). The manpage goes into more detail.
>Still, this seems to prove the point rather well - what other languages require you to keep the documentation open constantly due to unintuitive and inconsistent choices in basic syntax?
All of them.
Posted May 5, 2010 22:10 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted May 6, 2010 16:43 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Mainly because there is no syntactical difference between a string and a command. The reason why is explained here: <http://www.computerworld.com.au/article/279011/a-z_progra...>
As a consequence quoting is a nightmare, as explained here: <http://www.mpi-inf.mpg.de/~uwe/lehre/unixffb/quoting-guid...>
Also it has a extremely limited number of features. The Python tutorial is a very nice list of the features that shell is missing <http://docs.python.org/tutorial/>
Another big problem is the lack of namespaces but this latter one is not unique to shell.
Past some size any shell project should switch to Python or Perl. I actually have implemented projects that should have switched.
Posted May 5, 2010 14:42 UTC (Wed)
by k8to (guest, #15413)
[Link] (2 responses)
Moving this all to scheme would be worse.
Posted May 5, 2010 22:09 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Also, shell scripts are less readable than scheme once you get used to prefix notation. Stuff like ${foo##@(a|b*)} isn't readable by any standards.
Posted May 6, 2010 3:15 UTC (Thu)
by k8to (guest, #15413)
[Link]
I read and write, pretty fluently: shell, scheme, rebol, python, C, lua.
For its specialized domain, shell reads better than the rest. Scheme is definitely the worst.
Posted May 6, 2010 18:21 UTC (Thu)
by Thalience (subscriber, #4217)
[Link]
Rather, the problem is the overhead of forking a new interpreter for each script. Each of these processes incurs not only the basic fork overhead, but also has to go and re-parse a series of conf files. Several different (and complementary) ways of addressing this overhead are discussed.
One point is that a part of the system setup code (the stuff that sysvinit puts in /etc/rcS.d/) isn't really doing "script-like" stuff. It isn't constructing long unix pipelines or parsing text output from said pipelines. Rather, it runs utility programs (mount, fsck, readahead) with fixed arguments, or writes values to sysfs or procfs files. That is the portion that could usefully be integrated into the systemd binary itself. Perhaps controlled by a single conf file that systemd parses just once.
In contrast, I don't think anyone is interested in re-writing the contents of /etc/rcS.d/* as 50 individual C programs.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
> PA has been the project to end all that madness
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
For example, when people complain about weirdness when changing the volume, that is probably because PulseAudio is trying to make it consistent, but ALSA is lying about amplification levels.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
No, this is my personal side project. Also, let me emphasize this: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else."
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
> daemons should start. When it is unplugged, there is no need for them anymore, so they
> should be stopped.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Well, if your daemon has a memory leak, it's certainly faster to start it from scratch than to swap it in.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
For example, don't start cups unless there is a printer somewhere.
This could improve out-of-the-box security, which is always a concern.
Poettering: Rethinking PID 1
> get to "five nines" of uptime. Sometimes you are upgrading your kernel or
> hardware, and you just have to reboot. It needs to be quick.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
> by a daemon listening to inotify or similar by now.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
> better than updatedb in this day and age?".
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
files accessible to the user but not accessible to root
They must be easy to back up, with properties like that.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Heartbeat replacement/integration
Heartbeat replacement/integration
Heartbeat replacement/integration
Heartbeat replacement/integration
Heartbeat replacement/integration
Heartbeat replacement/integration
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
each time a job is started it is done in ignorance whether it is already running
Poettering: Rethinking PID 1
Bit confused here. I think you would agree with me that for cronjobs where it matters that 1) they run at the scheduled time and 2) there is only one running instance, some amount of intelligence in the job itself is what is needed?
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
They are all replacing stuff which has been working for years, where users now how they work, and are replaced with hard-to-introspect-from-the-command line stuff, nobody knows how they work, which are still buggy because they are still new, and if the cool guy who developed them decides for something else, replaces them again.
</rant>
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
With PA, and with no other changes, the same application does not work.
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Most less expensive devices don't.
Poettering: Rethinking PID 1
>Most less expensive devices don't.
Poettering: Rethinking PID 1
Subsystem: ASUSTeK Computer Inc. P5B
Flags: bus master, fast devsel, latency 0, IRQ 22
Memory at ffaf8000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: HDA Intel
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
Poettering: Rethinking PID 1
So there is Upstart.
Lennart sees some issues with it.
Instead of helping making it better he writes its own tool.
And I guess he will push it into the distros.
Then we'll have a mess of some systems using BSD-style scripts (Slackware), some purely SystemV scripts, some Upstart and some Lennarts daemon.
At this point we can finally stop pretending that a Linux box is easy to understand, since each distro will from the start work differently.
Wait, does he, who messed up Linux audio to some extend now seriously try to replace upstart, which is still in the process of replacing init ?
Poettering: Rethinking PID 1
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
if [ `cat $foo |grep ^bar &>/dev/null; echo $?` == 0 ]; then
echo `cat $foo |grep ^bar |awk '{print $2}'`; fi
done
Shell Scripts
Shell Scripts
Shell Scripts
It's a real shame people don't know how to use AWK properly. It's a fairly capable little language. One of the common abuses is piping grep to AWK - as AWK applies regexes itself to every line[1]. Basically, if we can assume input tends not to be huge or that most the input will be acted on, then whenever you see:
Shell Scripts
grep XYZ | awk ... '{ ... }'
awk ... '/XYZ/ { .... }'
find /path -name someglob | xargs awk '/^bar/ { print $2 }'
find /path -name someglob -exec awk '/^bar/ { print $2 }' {} +
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
The fact that people use cut, awk, sed, grep etc. in init scripts clearly shows that they do more than just launching programs, i. e. string manipulation. So given that it's done anyway, why not give people good tools to do it, instead of relying on 30-year-old concepts that turned out to suck?
I also disagree that bourne shell is often spoken well. It is *hard* to write good shell scripts, and most people can't do it. The result is that most scripts are fragile and slow.
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
That only proves that you don't know it very well :)
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts
Shell Scripts