Slashdot Mirror

It's not clear that it's actually required.

It's worse than that - not only is it not clear that it's actually required, I (and other) want to know why they aren't just writing a simple userland library that uses TIPC, which is already in the kernel. Even if there was some legitimate reason to need a kdbus-like feature that that wasn't already supported by TIPC, wouldn't it make a lot more sense to extend that existing, already debugged code and extend TIPC with the that feature?

Here's a gem from Poettering, where he dismisses basic security (why would you not implicitly trust unauthenticated packets from some random internet server?), as well as displays his total lack of awareness of the capabilities of the existing software he's bent on replacing (super-NIH syndrome... writing a simplistic replacement to ntpd and chronyd without even knowing what they currently do).

Yikes.

Things really *are* bad, aren't they?

Yes. They are that bad. Read the threads about Gnome vs. systemd-timesyncd vs. Chrony and weep.

http://www.spinics.net/lists/f...

And Poettering in his usual ignorant condescending style:

http://www.spinics.net/lists/f...

Things really *are* bad, aren't they?

Yes. They are that bad. Read the threads about Gnome vs. systemd-timesyncd vs. Chrony and weep.

http://www.spinics.net/lists/f...

And Poettering in his usual ignorant condescending style:

http://www.spinics.net/lists/f...

It absolutely is true for system utilities (like init). Vim is a text editor. It edits text. It does not edit graphics, init the system, act as a login daemon or multiplex your shell. But then, it's not a system utility. Look at awk, sed, grep, less, etc etc. Look at getty and login. Look at screen.

Exactly. But look at all the systemd "system utilities" like systemctl, journalctl, machinectl; they all work exactly like any other first class Linux system tools; they all only do one thing but do it well, they can be piped, they aren't chatty when successful (and actually care a lot about exit codes), aren't interactive etc, care about text output formatting (turn off legends etc) so they are perfectly scribtable.

The point is that all the systemd tools are doing everything expected by system tools according to "Unix philosophy".

Did you know that in Debian Wheezy there are TWO init systems that work at the same time? They weren't designed to do that but because they do things the Unix way, they don't 'mind' either.

I must say I can't see a reasonable use case for this. Sounds racy in all circumstances.

But here's a "funny" where systemd is most definitely wrong (yes, I have actually been giving it a chance, I just don't like what I see). I have a VM where I have yanked a virtual disk out from under btrfs. My fstab states that I want it to mount in degraded state if necessary (such as if a disk is missing). systemd *REFUSES* even though I explicitly commanded the action. How is that the Unix way? How is that supposed to help uptime? Thank the gods it's not a production box! Then I google as to why that might be and first post I find is some someone claiming IT'S A FEATURE! So there we are, the admin and owner of the box says just do it and damn the consequences and it refuses like a Windows box.

Take a look on these discussions;
http://www.spinics.net/lists/l...

http://lists.freedesktop.org/a...

Basically, systemd requires manual intervention to allow to boot btrfs arrays with both /a missing disk/ and in /degraded mode/
Not a bad default really.

Anyway, in order to allow btrfs to automatically boot in degraded mode with missing disks, and doing it /correctly/ you need some extra module/script/daemon to handle it, since neither the kernel nor systemd (udev) have any knowledge about the internal state of btrfs. Nothing new in that, raid etc. have always been handled by such a daemon. I think that if you use mdadm with btrfs raid, you can automatically mount degraded mode arrays. The critical point is the timeout timer; a crude method that needs to be set according to the particular array in question.
Bringing up a degraded array as RW risk killing the whole array, so it is not something to be done just because a drive is late at appearing.

http://git.neil.brown.name/git...

Now, just to complete the picture, do you know what journalctl told me about what was failing and why? It said the mount timed out. THAT IS ALL. Is this the system I am supposed to trust in production? The one designed by people who KNOW what they're doing?

Isn't that all you need to know to find the error?
Also, use the "-x" with journalctl, it may give further info to generic error messages and even link to more info.

Anyway, systemd have excellent debugging facilities; try to turn on debugging ("kill -56 1" from the CLI, or by setting "MaxLevelKMsg=debug
MaxLevelConsole=debug" in "/etc/systemd/journald.conf" and restart (journald or the VM)

Digging in to it, I fin

RTLinux as a solution is not (hard) realtime as they falsely claim it to be. Only the Hypervisor is realtime, but the Linux kernel running as a process is not, since it can't guarantee that it will respond in a deterministic manner. That's the problem with the PREEMPT_RT patch too.

With the Linux kernel, you get an average timeframe for an interrupt. With QNX or other proper realtime OS's, you get a Max timeframe.

Factual inaccuacies galore. RTLinux does not use a hypervisor, it uses a microkernel. Nobody claims that the Linux API in RTLinux is realtime, only the microkernel API, which incidentally is hard realtime with latency guarantees measured in microseconds. The PREEMPT_RT patch does in fact attempt to provide hard realtime, for example, interrupts become preemptible with real time priority. The question of whether PREEMPT is actually hard realtime or not gets into a debate over what hard realtime actually is. If measuring latency and finding that it never goes outside of strict bounds counts, then yes, PREEMPT_RT is hard realtime. If a mathematical proof is required, then no, however... nontrivial hard realtime systems that are fully proved are vanishingly rare.

For future reference, I found the message for the commit that changed CONFIG_PHYSICAL_START to 16MB from 1MB: http://www.spinics.net/lists/linux-tip-commits/msg02353.html

I actually fixed one of these bugs in the kernel last month.

But you are right that these are very rare. I have did a git search of patches which only add a single '=' character and there are normally two kernel bugs like this per year. In other words, we have 50,000 patches per year and only 2 patches have this sort of bug.

I have spent quite a few days auditing for these bugs in the kernel. They were rare the first time I audited in 2002 but these days we have several ways to make them even more rare.

Imagine you have "if (x = foo) {":
1) GCC suggests using extra parenthesis around the assignment like "if ((x = foo)) {"
2) Checkpatch.pl suggests breaking it up into two statements. "x == foo; if (x) {".
3) Static checkers complain about it if foo is a constant, or if the checker is in verbose mode, then it complains if foo is not a function call. (A lot of static checkers complain. It's a favorite thing to look for).

One thing that I have just thought of is that we should have a warning where checkpatch.pl complains if people do: "if ((x == foo) || (x == bar)) {". Sometimes it's hard to know where to add parenthesis for readability, but for comparison operations the parenthesis are obviously bad style.

The question is really going to be what kind of shape the drives will be in a year or so

Thing is, you don't need SSD on every partition of a server. Just putting /var on a 10G of a 60G SSD RAID1 will get you some really awesome performance (Apache+mysql) with a fair amount of over-provisioning so you don't have to worry* about TRIM (which is panning out to be nothing more than benchmark magic anyhow) or killing the disks early. You get lots of IOPS to spare, especially on reads, so running mysqldump every hour or whatever may be within reason now without seeing a huge I/O bottleneck. Replace the SSDs every year. The performance gains will be worth the cost. smartctl will tell you the operating hours on the drive to make it easy to remember.

[*] - http://www.spinics.net/lists/raid/msg40866.html

"Show me evidence of a glitchy driver causing a loud squealing noise, the wireless chipset to stop working, and horizontal lines on the display."

AAHHHHHHhhhhhhhhh, the memories, they are back after I tried so hard to forget the S3 Virge driver:
http://www.spinics.net/lists/xf-xpert/msg05481.html

Wireless chips that stop working, I have seen people complaining about some Intel and Broadcom chipsets, fairly recent. I used to have some kind of BCM (4328 IIRC) with ndiswrapper, occasionaly stopped working (once 1 a month or 2).
http://linux.bigresource.com/Ubuntu-Networking-Wireless-connection-stops-working-randomly--AWdGAzaK2.html

What the hell does "DCE6 display watermark support" mean?
I googled for it and didn't find anything useful.

Whoa, this one really flies below the Google radar. DCE part of recent Radeon architecture, a programmable display controller that produces low level digitial signals to drive a wide variety of display types. As for "watermark", I did not turn up much on it beyond the patch. You tell me and we'll both know.

Could you find anything newer than January 2007 to generalize that the entire Open Source universe is populated by rude people. ref and it's considered rude not to provide links to what-so-ever you are refering to.

I don't know about the OP but with 3.0.7 I still experience the same bug as here.
Properly reported but hard to fix...

That's easy with a 0day exploit. However, it wasn't that easy, as you see some of the intruders exploits crashed the
kernel. e.g.:

http://www.spinics.net/lists/kernel/msg1229170.html

note the:
> [ 71.610908] Xnest[4485]: segfault at 7f51210dfaa8 ip 000000000040c544 sp 00007fffdadb5970 error 6 in .p-2.5f[400000+15000]

> .p-2.5f = phalanx 2.5f rootkit [currently, not being detected by chkrootkit and khunter]

I agree with a lot of what you said, so take my silence on any issue as agreement.

It does not add any functionality that you actually need, but it does add a lot of incidental complexity.

I understand the concern from a scripting standpoint. But I wouldn't say it does not add useful functionality. On the remote side (when a server stores branches in different directories), it gives me a unique URL handle on each branch. This is invaluable, as I can say "push from here up to lp:myproject:mybranch", for example. On the local side, it lets me have a physical directory for each branch: I often work in multiple branches simultaneously (e.g., if I am working on a feature and find a bug in trunk, I'll Alt+Tab to my already-open trunk window and fix it there and commit it -- this saves me from the temptation of fixing a bug in the feature branch, which would bloat the feature branch unnecessarily.)

Re. revision numbers: Revision numbers are a fundamentally flawed model in a distributed world. In a distributed system there can be no consistent numbering unless you can and do enforce a global total order... which neither Bazaar nor Git do ... The fact that Bazaar just lies to you and pretends that there is a global total order is not a plus.

You're assuming that revision numbers need to be globally consistent in order to be useful. Once you understand how Bazaar's (admittedly complicated) revision numbering scheme works, you can find them useful even though they aren't globally consistent. Bazaar does not "lie" to you and it does not "pretend there is a global total order," ... you must have read the wrong manual. Bazaar is quite clear on the fact that revision numbers are specific to a branch. And yes, if you're communicating them, you do need to refer to the branch name and the revision number (or, if you don't, it could reasonably be assumed you are referring to the trunk). Here are some reasons why having systematically and contiguously-numbered revisions is helpful:

- Much easier to type or say than a hash (say I am communicating verbally, "hey Mike, there's a bug in trunk r135").
- Obvious order in most cases (142 clearly precedes 164; 142 clearly precedes 142.2.53).
- Obvious which revisions are the "important ones" (13 and 183 are on this branch's main line -- for the trunk this means they are stable commits; 45.1.14 was clearly an unimportant commit to a branch that was merged into this one).
- Most importantly, for a given merge commit, obvious which parent was the previous commit to this branch (for r14, it is r13) and which parent was from the branch that was merged in (say, r11.1.5). This is a critical advantage of Bzr over Git -- Bzr trees keep their "shape" whereas Git trees are just a pile of commits with parents.
- The "distance" between two commits is clear; it is obvious that 13 and 15 are much closer together than 13 and 165.
- For any two branches, all commits made before the branching point (where the two branches split) have consistent revision numbers.

All of this far outweighs the fact that you have to be educated and careful about the fact that a Bzr revision number means different things in different branches. It takes some getting used to, but so does referring to everything by a long and meaningless series of letters and numbers. Even Linus agrees: he plans to add "generation numbers" (a very weak form of Bazaar's revision numbers) and in this email, he stated that "the lack of [generation numbers] is literally the only real design mistake we have."

Keep up to date backups of any important data:
http://www.spinics.net/lists/pgsql/msg122280.html
http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html

I'm tempted to get an SSD (or two), but the failure rates seem rather high, and the failure modes too often are worse than normal HDDs (drive totally dead or even "time warp" drive rolls back to a state X days ago : http://www.ocztechnologyforum.com/forum/showthread.php?83778-Time-warp-drive-vanishing-after-3-days-data-gone-on-reboot...I-need-3-to-5-users-with-this-issue-to-help ). The time warp failure mode doesn't puzzle me that much, I can think of reasons why it would happen - but it worries me from a design perspective.

Yes normal spinning disk drives do suddenly fail completely too, but that normally is a result of abuse. So far what normally happens is you have bad sectors and/or the SMART reporting stuff starts giving you some ominous signs).

If the SMART stuff worked well for SSDs, even if SSDs failed every 3 months or so, many would be happy enough - they'd buy a stack of SSDs (yes really) and swap them in whenever they see the SMART warnings.

Great. Now I can haz case insensitive filenames please?

The previous answer boiled down to "the appropriate time to make the change is a development kernel such as 2.7."

If have one of these problems also.

I'm not sure if this is your distro's bug, but one of mine involves Ubuntu's network-manager over WPAand I can barely remain connected since maverick; prior to that, there were serious problems in just handshaking.

At the time you posted, I was halfway through test-driving the recent KDE 4.6 after dumping Fedora back in 2009 or so. I still had to use my WPA-free network. Back in 2005 the problem was that distros didn't support your wireless card; laptops were fairly new at luring devs to support 'em out of the box. It seems wifi support on Linux is in a perpetual beta, akin to sounds issues that still sometimes resurface after 15 years of being an issue. Intel is working to release microcode to resolve some of the AGN problems.

Does that include full 64-bit compliance? If so, Linux fails:

While you guys are at it, you might consider preventing sendto(), etc.
calls from requesting >= 2GB data in one go. Several families have no
restrictions on total size (or even worse, assign the size to a signed
int type and then do a signed comparison as a check). This can result
in all kinds of ugliness when allocating sk_buffs based on that size,
some of which result in kernel panics (due to bad sk_buff tail position)
or heap corruption.

Well, that's not an unreasonable limit, you say?

Yep, because 640K, errr, 2GB should be enough for anyone.

One thing you are seeing now is the proliferation of versions of Android out there. In other words, maybe Google is making the same mistakes Microsoft did with "DLL hell", only much worse. This would seem to me to make it difficult for the third party vendors out there. With Apple, I have to test for iOS 4.1, 4.0, 3.2, 3.1, maybe iOS 2.0. With Android, throw in more versions, and more hardware, and you've got some additional complexity.

Another interesting advantage of iOS is that Apple doesn't have to convince Linus, as Google does, to make a change to Linux to support devices vastly different from the typical hardware Linux runs on, from big iron like IBM mainframes, to powerful Unix servers, to laptops. There was a fascinating thread on the Linux Kernel a while back about Linux Power Management, all about sleep mode, etc. Fascinating in that it gives insight into the tremendous amount of thought that goes into what might seem a trivial problem, but then you realize how this might impact other systems, well, it isn't so simple. Is this due to Linux monolithic kernel, vs. the mach kernel used in iOS? Just a thought. Anyway, it occurred to me reading this thread, that Apple has a significant advantage in not having to convince a third party to make a change like this.

Race?

The most popular distros already patched it days ago and others are currently in testing.

Redhat patched it 2 days ago.
Ubuntu patched it 2 days ago.
Fedora is currently testing the patches. Not sure if it's already live.
Debian Lenny has patched it.

Our 8TB raid system would get trashed after copying data onto it (group descriptor checksums on fsck). It looks like it was an ext4 bug. They fixed it about a week or two ago, here. Maybe it will get in your kernel soon. I'm not going to start ext4 on any production system for at least 6 months I think now.

A good portion of the kernel is GPL V2 but not all. Contributors decide what license their code is under. Read the discussion in the lkml: http://www.spinics.net/lists/kernel/msg435586.html

Take a quick look at their "case study" and google the company involved, Mendara Systems:

http://www.ale.org/archive/ale/ale-2002-10/msg0023 8.html

http://www.spinics.net/lists/rh9/msg04983.html

I wonder if Click Defense and Mendara Systems are all the same "company."

This isn't the only screw-up for Alenia this mission. Look for articles involving the Ka Band Translator if you're interested. You may not find many, it hasn't been covered very publicly. Basically, we can no longer send a Ka band uplink to the spacecraft becasue the Alenia built receiver broke. See Paragraph 10 here

Meanwhile, additions to Tiger's [...] "Security" preference panes have unveiled [...] an option to encrypt memory when its being swapped to disk.

Wow, that's paranoia! :) I guess Apple is taking pointers from Linux users. I found this script to encrypt swap -- what other options are there under Linux? Windows?

In the meantime, I
will defer applying the licence change to any client-side library code.

In the meantime, I
will defer applying the licence change to any client-side library code.

In the meantime, I
will defer applying the licence change to any client-side library code.

Absolutely not! That would be totally unprecedented!

I'm as much a linux fan as any other geek, hell I rely it on for my home, business, and university servers.

But anyone who has run a linux server as a true multiuser system (i.e. with other people users, who have standard userlike weaknesses) has discovered that the linux kernel isn't as robust as say the BSD kernel. It's easy to bring a linux system to its knees with malicious or even accidental user scripts that fork bomb etc.

Slightly different angle now, but check out this developer's response to the latest ptrace vulnerability: "it's a local root hole, and there are still tons of those left out there to squash". And once those are squashed, there are lots of EZ denial of service glitches to correct too.

I would love to see the linux kernel made more robust, like the BSD kernel. Now, whether or not Novell are the people to do it, I don't know. Personally I think that linux is still better than any Microsoft or Novell "enterprise grade" solution.

I seriously doubt large companies have the ability, or the interest, in making any operating system truly robust. But "we" can do it I'm sure, because we know what we really want.

Alan's Patch does not apply cleanly to 2.4.20. This one should.

--
http://www.niconet2k.com

Further in the thread, there is a patch against 2.4.20.