Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment: Re:Why? (Score 1) 231

by Peter H.S. (#49565601) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

PA can provide both things, by suspending out if your need shift from consumer audio (PA) to Pro audio using jackd. No need to dedicate your box to either; they can both work for whenever people need different solutions.

Are you really saying that a feature of pulseaudio is the ability to disable pulseaudio and use something else?

Yes I do. It is great that you can use exactly the program you need, even if their usage normally are orthogonal. Please note that PA doesn't disable itself, it just automatically suspend until needed again. PA and jackd where made for different reasons and solves different problems.

I see a lot of posts complaining about anti-systemd zealotry here, but clearly there is a lot of zealotry all around. I can't recall any other topic in Linux history that has been this divisive, and that is part of the problem.

Well, some people thought they could stop the systemd progress by waging a negative campaign against it and its developers. That of course was a predictable failure.

Personally I don't care whatever init system people run. Even if I find e.g. SysVinit inferior to systemd I have no problem with people using it, and they owe me no explanation for doing so.

Systemd-opponents don't agree upon what they do like, they can only agree on what they don't like. This make their tactics so rabid and aggressive when attacking systemd, its developers, the distros that uses it and even its users. They simply don't have a positive alternative they can agree upon, so they are left with negative attacks.

Comment: Re:KDBus - another systemd brick on the wall (Score 1) 231

by Peter H.S. (#49565385) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Yes, and most of that existing industry will have to rewrite everything from scratch without file format compatibility.

journald has excellent export capacity, it is trivial to convert everything into JSON or similar industry standards without tedious data massaging. Unlike the many slightly varying syslog implementation with deviating output, journald output is always predictable since has a stable API and is structured around fields. This is a massive win for everybody, especially those who needs to put their logs into full DB's (for legal or whatever reasons).

"Another problem with text log files are their limited ability to incorporate much meta-data, since that makes the log lines unreadably long. So having full microsecond precision and monotonic timestamps is a problem."

Really? Here's the microsecond monotonic timestamp on my current box: 242841.31760194. That's 15 bytes. A 64-bit binary timestamp is 16 bytes. The text version is shorter! And given that the vast majority of usages do not require microsecond resolution (which isn't even really accurate, anyhow), the text approach would lead to substantially _smaller_ files.

Adding full microsecond precision and monotonic timestamps and wall time timestamps + all the other interesting meta-data and the log message itself, are making the text log entries extremely long and unfriendly to read for humans. With journald you only see such meta-data info if you ask for it. Much better solution. And if you are concerned about log sizes, journald has transparent compression. With text logs you need to unpack or use specialised tools to manipulate them if compressed.

Plain text logs sucks for so many reasons, their only redeeming feature seems to be you don't need to pipe them through a tool in order to read them.
I have much respect for the Rsyslog developers, and I remember how I hoped they would fix the most of the glaring syslog problems when they started out a decade ago and in their own way tried to solve the problems that journald does. They partially failed, not because they weren't good, but because changing certain stuff in Linux userland is extremely hard.

Comment: Re:KDBus - another systemd brick on the wall (Score 1) 231

by Peter H.S. (#49565163) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

sysvinit is crude and simple because it pushes all complexity out of init into userspace and because it offers no worthwhile init functionality. That is why Linux endured decades of remote exploits since SysVinit wouldn't take responsibility for dropping daemon privileges or do socket activation like systemd does, so daemons didn't have to use complex and error prone privilege dropping code just to get a port below 1024.

With systemd and new style daemons you can just avoid all that crap in the daemons. Much better to have one central place for security code made by experts than each and every daemon needs to compensate for the abysmal lack of functionality and security features of SysVinit.

I don't care if some people think that SysVinit is the best init system ever made and that it has no errors and can't be improved and Linux should use it forever and ever. We happen to be a lot of people who don't see it that way, which is why we like systemd and chooses distros that support that.

Comment: Re:KDBus - another systemd brick on the wall (Score 0) 231

by Peter H.S. (#49562391) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Or, you know, pretty much noone really cares about having indexed and structured log files. Separating into log files based on hostname and application name has worked really well for me for ages. And, because you're still going to have a human write the log messages, you're still going to have to eyeball the output at some point.

Great that syslog works for your usercase. I doesn't for me and so many others. There is an entire industry build around the need to beat syslog files into some sort of structure and give them an index so you can do number crunching on them.

These days log files grows so fast and is so important for business decisions that only machine parsing can do the job properly. The journal is excellent in that regard too.

Another problem with text log files are their limited ability to incorporate much meta-data, since that makes the log lines unreadably long. So having full microsecond precision and monotonic timestamps is a problem.

Yes, at some point a Mark I eyeball is going to look at a tiny subset of the data, but these isn't a problem either with systemd's journal; all the usual standard Linux text tools work through piping. And there are language bindings up the yazoo so you can manipulate it the journal files directly with Python scripts etc. It is so easy to extract the data that you need.

Personally I find syslog text files pretty hostile to newbies; unless they grep well and know a variation or two of regex, they are bound to just plow through the logs trying to identify some error. Really, many of them even resort to editors for reading log files. And the DE developers can't make a distro agnostic GUI log viewer better than "less" because there is no stable text log API. With systemd's journal they can because it has a stable API and language bindings etc.

With journalctl it is so easy to make even powerful extractions like; just show me logfiles generated the last 5 minutes (journalctl --since -5m) or all errors with syslog level "warning" and above created since this boot (journalctl -b -p warning). There is tab completion of every command option and every journal field and ususally even of the values of those fields. No need to memorise obscure arguments and subsystem names.

Comment: Re:KDBus - another systemd brick on the wall (Score 1) 231

by Peter H.S. (#49561609) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Rather typical LKML discussion in my opinion, but blown out in all proportions by the systemd-haters because they wrongly think that Linus don't like systemd nor its programmers because of this.

No it wasn't. Linus made his views on when this stuff will get merged, if ever, abundantly clear. It's not blown out of all proportion. That's what was written.

You don't seem to have experienced many LKML flame fests before, so I think you will be sadly disappointed when Linus merges kdbus.

Comment: Re:Why? (Score 1) 231

by Peter H.S. (#49561543) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Linus Torvalds have long signalled that he wants kdbus in the kernel.

No he hasn't you liar. I'm afraid this propaganda ain't going to have any effect whatsoever on his views.

Have you even read the lkml? Linus is deep into discussion of the code and even defended kdbus design decisions. He would never do that if he didn't intend to merge it as some point when enough people thought it was good enough.

Also notice how Linus appeared in the first kdbus patch threads. He didn't comment on the code, so the only reason he mailed was to signal to everybody that he followed this, and this was just business as usual.

Sure, the kdbus maintainers will have to do a good enough job in fixing problems before it is merged, but as it looks now, this doesn't seem to be a problem.

kdbus is good stuff that can benefit everybody, and while it isn't a shining-new general purpose IPC that some kernel developers want, it does solve real world problems, and that is exactly what Linus think his kernel is all about.

Comment: Re:Why? (Score 1) 231

by Peter H.S. (#49561411) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

You know what's different about consumer and pro audio? Nothing. As it turns out, consumers also want high-fidelity audio, and they want to be able to mix multiple streams. The only difference lies in what the industry is willing to sell us.

This not about spending money or HiFi, but on what you use the audio system for. On consumer audio you want low cpu and battery drain and accept the tiny latency associated with this; that a music stream start 20ms second later doesn't matter. It is also important that features such as streaming, bluetooth head sets integration etc. works out of the box etc.

With Pro audio latency is king. cpu and battery drain means nothing.

PA can provide both things, by suspending out if your need shift from consumer audio (PA) to Pro audio using jackd. No need to dedicate your box to either; they can both work for whenever people need different solutions.

Actually, pulseaudio has notably drained batteries in the past, because shitcode.

A bug from 2007 on Ubuntu that famously fouled up their PA implementation, hardly a serious complaint. This 2012 shows how PA even beat Androids audio stack (Audioflinger) regarding CPU and poweruse.
http://arunraghavan.net/2012/0...

There are several such benchmarks that shows how good PA is in this regard.

Comment: Re:KDBus - another systemd brick on the wall (Score -1, Troll) 231

by Peter H.S. (#49561183) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Unlike you I have several years of experience with systemd. You just seem to parrot the party line propaganda from the tin-foil hat systemd-haters.

Don't run with the pack. Try to actual examine systemd by reading the documentation and get some experience yourselves. It takes some time to really understand how systemd works.

Comment: Re:KDBus - another systemd brick on the wall (Score 0, Troll) 231

by Peter H.S. (#49561077) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Did you actually read my post which was about a very specific point about binary versus text versus INDEXED text log files

systemd's journal is a basically a textfile that uses another line delimiter and have an index. Try "strings" on it, or a hex editor.

Well if so, that's new. It never used to be the case that the binary format was stable. So, I'm going to ask you to provide a link to the description of the binary structure.

Here is is the systemd interface and portability chart. Notice sd_journal and the journal file format:
http://www.freedesktop.org/wik...

Here is the file format;
http://www.freedesktop.org/wik...

There are loads of other developer information about accessing the journal with Python language bindings etc.

Jesus fucking H. Christ on a stick what is wrong with you? I specifically went into detail about how noisy the pro-systemd people like you insist on a dichotomy between unstructured text files and binary file formats. There is no fucking dichotomy you moron. If you actually read my sodding post instead of going off on a rant then you would actually become marginally more informed and stop spouting the same old shit repeatedly.

Well, you are not the first person to think about how to extend text logs with some kind of index, and it would be nice if it could have microprecision timestamps, and monotonic timestamps like the journal does. The problem is that is unworkable.

As I said, several projects have tried to fix this without any luck for the last couple of decades.
Another problem with such a solution is that standard Linux text tools like grep, tee, sort etc. won't work with such a solution where the index isn't part of the text file, and metadata like microsecond time stamps tend to make the log lines unreadable long.

With systemd's journal all standard text tools work with the index and metadata, so you can grep monotonic timestamps by a simple pipe.

If it was possible to have indexed, and structured plain text log files that didn't require a special "translator" in order for the standard Linux text tools to work, it would have been implemented a decade ago.

Comment: Re:Why? (Score 1, Informative) 231

by Peter H.S. (#49560749) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

The whole point I was trying to make that looking back on sound on Linux in the days before ALSA and PA shouldn't be done with rose tinted glasses. Claiming that, like the OP does, that everything went backwards with the invention of ALSA and later PA is just absurd. Those where the bad days regarding sound on Linux. There is nothing to miss from those days, including ISA sound cards.

With ALSA and later PA there were actually people working on the Linux soundstack and developers that could coordinate bug fixing. And PA was a huge help for DE developers that where so tired of trying to maintain their own sound servers and dealing with really low level kernel stuff like drivers, when all they wanted to do was to develop for the desktop.

Comment: Re:KDBus - another systemd brick on the wall (Score 1) 231

by Peter H.S. (#49560525) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Practically nobody was using Upstart on Debian at that time according to popcon. That the Upstart maintainer voted for his own project was natural, but among the rank and file DD's the support for systemd was strong, while the fact that there was a Upstart CLA made it unacceptable for many others. I think it was only Debian's affinity with Canonical that even made it an alternative at all.

I think Ian simply cooked off in some major rage fit. He wasn't entirely rational about this issue after that.

Comment: Re:KDBus - another systemd brick on the wall (Score 0, Troll) 231

by Peter H.S. (#49560409) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

I'm not even going to get into a pro/anti systemd argument becauser that's actually not relevant here, but this is why people get annoyed with the systemd folks, because of the mindless zealotry/ignorance. No offence, but solutions to this have existed for YEARS and have been implemeted in plenty of other systems.

Really, please show me a non-systemd Linux distro that doesn't use scripts for setting up daemons and boot, thereby mixing code and config statements in one unstructured code lump that are hard to parse for both humans and machines. And does it provides high level API abstractions for cgroups and kernel capabilities so SA's can use them for all daemons just by adding a simple key/value line in a text config file?

I am well aware that SysVinit and endless variations like it such as OpenRC exist. But they don't provide any meaningful competition to the many features that systemd provides. You may be happy with SysVinit and its many limitations, but I and so many others aren't.

If you don't recognize how superior systemd is to existing alternatives, you also say that no new development is necessary for the non-systemd distros in order to stay competitive. I would like to see some real competition to systemd, but it doesn't happen, seemingly because the systemd-opponents have dug into their own grave claiming that everything existing is good enough and systemd is just bad. Shrug.

You have a text based log file, which just works with everything. You also have a separate binary index which indexes the textual log file. You get the benefit of fast lookup if you use the index and it will just work no another machine if the original tanks and you don't have the right version of systemd on the new machine.

You really are uniformed about systemd's journal; its structure and layout and API have been fully documented and is stable. That means you can read any journal with any systemd version. At worst you may miss out certain extra meta-information fields that have been added later, but nothing essential will be missed (and it will be information that any text based syslog implementation won't have anyway).

The systemd journal is designed to be read on other machines, and it does it exceedingly well, like reading from nspawn OS containers, etc.

Plain text log files have been a problem for Linux for decades, and many projects, including Rsyslog was started exactly to overcome the many limitations with both the syslog interface and the plain text log files.
The current journal file format, which is basically an appended text file with index, is a great compromise between having unstructured, unindexed text logs with no meta-data, and running a full sql-server.

If the non-systemd distros have a better idea, then great, let them implement it, but I fear the usual answer will be that text logs are the final word in logging, and that no new development is needed.

Comment: Re:Why? (Score 1) 231

by Peter H.S. (#49559949) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

A previous poster linked to a post by Eric Biederman that should be required reading for this Slashdot thread. I'm not sure which part to quote, because the whole thing is pretty damning: Kdbus needs meaningful review

On one hand, the post (and lack of kdbus in kernel 4.1) seem to indicate that you are correct, and the process is working. OTOH, Eric argues that:

  • Kdbus code is nowhere near ready for a merge, it hasn't been reviewed, and in fact may need major reworking before it can be used or reviewed.
  • Kdbus authors are pushing the merge very aggressively, and have made a habit of ignoring criticism and refusing to take steps necessary to even make the code reviewable.

You are interpreting this much too hard. Every time a new important kernel features come you have these kind of statements. The point being that some reviewers set the standard to "perfect" to begin with. That way nothing will be merged, so from now on people have to battle out the details until Linus is satisfied. Eg. Linus has personally stated that some of the criticism that Biederman repeats are wrong (about caps metadata in an exchange with Lutomirski).

All in all this is business as usual, and the kdbus developers have been very very quick to change anything specific that has been pointed out as problematic. That they are eager to get things merged is just how such things work, same with reviewers that says "hold your horses".

There are pretty good odds on that kdbus will be merged into mainline in not so far a future when things have been trashed out on lkml a while.

Comment: Re:Why? (Score 0, Troll) 231

by Peter H.S. (#49559827) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

When I tried to configure PA to use a sample rate over 100KHz last year, it consistently brought down the entire system. This was on a very capable machine, and high sample rates should be a basic use case for PA. I didn't dig into the cause, but it was PA itself that thrashed the CPU, so it seems unlikely that particular defect was caused by the layers underneath.

Please note that PA is for consumer audio, that means general purpose desktop and sound server use. It works great for that and doesn't drain batteries and so on. For specialized use or Pro audio where latency is king ALSA directly or jackd. No PA expert but if the driver/hardware doesn't support sampling above 96 kHz you should expect problems. +100kHz really is an unusual user case.

Always try to do things in chronological order; it's less confusing that way.

Working...