LWN.net comments

Ubuntu 8.04.1 LTS released

gavinmc — 2008-07-06T17:05:48+00:00

that sounds rather like this issue:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/75704

Is it an L400?  Did you try disabling ACPI?

Gavin

On the personally identifiablity of IP addresses

dps — 2008-07-06T14:43:17+00:00

Most IP address can be linked to a person, or group of people, given a time. If this was not
true then it would be impossible to get spammer's accounts nuked by sending the appropriate
information to their ISP. Some ISPs policies include penalties like hefty clean up fees or
your telephone[*] not working if your account is nuked for internet abuse.

Provided you do it soon enough the data logged by ISPs can turn an IP address and time into an
account name, which almost certainly constitutes protected personal information. At least in
the EU when one does get a reply to a spam report you never learn any names but do get the
account nuked.

FYI 80.176.136.7 is reserved for my use and use thereof is strong evidence I was responsible.
Fortunately I have a strong (dedicated linux IP tables) firewall box and mail server which
does not support third party relaying.

Duncan (-:

[*] BT broadband customers are liable to lose their BT telephone service in addition to their
broadband connection.

In other news...

dberkholz — 2008-07-06T14:25:23+00:00

Hey, we're not quite at Debian levels of release separations yet. =) Maybe next time, we can
aspire to that.

In other news...

tetromino — 2008-07-06T14:13:47+00:00

...pigs across the country have been sprouting wings, DNF is set to be released "real soon
now", and the Devil is having trouble with his central heating.

I hate Linux Graphics (Linux Hater's Blog)

kbob — 2008-07-06T13:13:00+00:00

Each of the O2 demos was a single process, as I recall.  Some of them were groups of earlier
demos glommed together, e.g., onto different cube faces, but they were recompiled into a
single executable.

They just demonstrated what the hardware could do.  That's why they were called demos.

1990s SGI

kbob — 2008-07-06T13:08:06+00:00

Yes, the O2 had a unified memory model.  2D, 3D, the video decompressor, and video inputs all
wrote to pbuffers, pbuffers were used as texture inputs, and one pbuffer was fed to each video
output DAC.  It allowed things to be plumbed any which way.

SGI's higher end graphics systems at the time, Impact and Reality Engine 2, were optimized to
render directly to the screen, but could also render to pbuffers.  They also didn't have the
video inputs by default.

Yes, I worked on O2, though not on the graphics subsystems.

Mozilla plans for Firefox 3 and beyond

mmarsh — 2008-07-06T12:46:03+00:00

The "better system integration" that I'd like to see is "the host has a CPU running at X MHz
and Y MB of RAM, so I'll tune the effects and caching appropriately."  Yes, a lot of this can
be hand-tweaked, but first you have to figure out what those options are, often modifiable
only through about:config and a cryptic integer value.

This base is covered too

khim — 2008-07-06T11:22:49+00:00

For a business difference is not so big: you must keep a lot of logs anyway (or else you can be sued) so it does not matter who and where keeps the logs. And it's done for the cases like that so you can be sure court will come to get your logs...

Re: Xorg 1.5 missed the train?

nix — 2008-07-06T11:07:07+00:00

... if you ignore ATI hiring open source developers to work on open source 
drivers and opening their docs, sure.

Nvidia has been supportive of people who want to use their cards on Linux 
systems and don't care if the driver is free or not, but that's as far as 
it goes.

Re: Xorg 1.5 missed the train?

ajamison — 2008-07-06T10:20:36+00:00

Wow you know I am not a developer but I agree with you here. My view is this when NVidia
decides it is time for an updated driver to work with the current Xorg version then they will.
Generaly speaking between the two power house Graphics card vendors (ATI and Nvidia) Nvidia
has allways been quicker to realease new drivers and generaly been more supportive of open
source developers.

A look at openSUSE 11.0

thoeme — 2008-07-06T10:01:58+00:00

I am writing this on a newly installed openSuSE 11, using KDE 4.0.4.

It is true that KDE 4 leaves somewhat mixed feelings about its
configuration, which also stem from my feeling of not doing it the right
way (who says it has to follow the rules of KDE 3.5 ?)

Some things are plainly wrong (online software update stopping even when
the list of packages to update has not yet worked off, asking the user if
more software should be installed; kdesu ignoring the check mark on
"remember password")

Some things are weird (not being able to put a program icon on the desktop
to run an independently installed FireFox; a "right-click-thing" in KDE
3.5; choosing "Enforce DPI" to "96dpi" in the "Font Selection" changed all
fonts from sans serif to courier).

Stuff I am not really used to anymore, since back in the old KDE 2.x
days... 

But I am sticking with KDE4: If nobody is using it, it won't improve. 

But aside some other personal dislikes like coloring and themes, it is a
pretty slick distribution. I must be also one of these last people which
still buy boxes, and I don't regret it.

regs,
thoeme

Stable kernel 2.6.25.10

nix — 2008-07-06T09:02:30+00:00

To me, the fact that it breaks GDB is more significant, but then I don't 
have dedicated maniacs attacking my systems with billions of 
custom-written ptrace()s (and if they did, it would take them days and 
there's no way I'd not notice even if I was on another continent).

2.6.27 KVM numbers are incorrect

Felix_the_Mac — 2008-07-06T06:59:18+00:00

Thanks for the explanation.

"So 2.6.27-rc1 will roughly contain kvm-70 plus all bug fixes since applied."

Unless KVM-71 comes out soon! :-)

More DTrace envy

paulj — 2008-07-06T06:10:32+00:00

You're the second person to have misread my (I thought fairly clear) comment, so I guess I
need to reply and clarift: I specifically said that *your* opinion of Suns' motivations in
choosing the CDDL was largely irrelevant (not least because motivations, even when generally
acknowledged, aren't that relevant).

Next (sorry to restate, but its important to the coherence of this post) you have been given
several reasonable, practical and good reasons why the GPLv2 would not have been acceptable to
Sun, regardless of Suns' motivations towards Linux, namely:

- Sun did not want to dictate to ISVs that they must GPL their code. (This one you have heard
directly from Bryan)

- Sun does not want licence-forking (to cover any rebuttal to the previous point of "so use
LGPL", as the LGPL can be converted to GPL, and ignoring the fact that the LGPL is far from
pretty)

- The GPLv2 is out of date with regard to patents. That Sun added patent cross-licensing+MAD
terms to CDDL suggests this may have been a factor. (Why it applies only to CDDL? I've no
idea.. I suspect there may be legal, technical difficulties in drafting the language to have
many other licences - particularly with regard to the 'MAD' aspect of the CDDL patent
language. Can you provide a pointer to the grants you refer to? Be interesting to read).

Next, ignoring the above and if we accept your argument: Exactly how did you develop this
massive sense of entitlement that you think it is your automatic right to Suns' code on
licensing terms favourable to your chosen OS? I'm a Free Software Foundation supporter and I
always understood that the ethical reasoning for companies to choose the free software was out
of respect for their *users*...

Finally, can you tell me with a straight face that had Sun chosen the GPL but it had chosen
the GPLv3 (imagining the GPLv3 had existed), that you'd then not be complaining here today
about Suns' choice of licence? Even though it too is incompatible with Linux to the *same
extent* as the CDDL is (namely: it'd require linux copyright holders to agree to update the
Linux not-quite-GPLv2 licence)?

Stable kernel 2.6.25.10

PaXTeam — 2008-07-06T05:55:23+00:00

> null function pointers are only exploitable if vm.mmap_min_addr is zero,

no, if a process has CAP_SYS_RAWIO it can also evade the 0 mmap restriction (and let's ignore
the early implementation bugs of this feature). if a process doesn't yet have CAP_SYS_RAWIO,
it can 'acquire' it by exploiting another that does have it (think of X for example or any
suid root process). or alternatively, one has to use SELinux and make sure no process can be
granted MEMPROTECT__MMAP_ZERO. and all of this breaks valid userland programs, so it's not a
universal solution (it's default off for that reason).

> which should not be the case on most installations.

any statistics to back it up? remember, it needs both CONFIG_SECURITY and be set to some
meaningful value.

in any case, i'm not sure what you were trying to say, if a bug falls into a known exploitable
bug class then it should be reported as such (or briefly explained why it's not what it looks
like), regardless of what mitigation factors may apply in a given installation. such info
belongs to vendor advisories at most, not a kernel commit message.

> I imagine getting 4G references on a task_struct would be hard without
> root privileges.

the patch fixes a few ptrace commands that can be issued by any user, not only root. therefore
it's triggerable and exploitable by any user who's not otherwise prevented from using ptrace.
as for the technical feasibility of issuing 4G ptrace calls, on a core2 a single GETREGS takes
less than 30 usec, that's less than 2 days of runtime.

Stable kernel 2.6.25.10

nix — 2008-07-06T05:49:13+00:00

If they're in an array of structures and you can integer-overflow the 
array index, suddenly they're dangerous again.

Developers are the wrong people to ask

pointwood — 2008-07-06T04:53:00+00:00

Of course, it depends on your definitions, but I think you'll be a bit surprised by the
improvements already available in KDE 4.1. I've used KDE 4.1 beta 2 for a few days and except
for stability problems in various places, I'll rate it as fully usable. I tried 4.0 and dumped
it very quickly since I found it to be more or less completely unusable. I'm running Kubuntu
and their next release will be based on KDE 4.1.x and based on what I've seen from the beta
release, I'm not really worried.

Plasma is a highly visible component of KDE 4 and sadly it was also the most unfinished part
in KDE 4.0. It being massively improved in KDE 4.1 also makes KDE 4.1 a lot more usable. 4.1
is clearly still an early release of KDE 4 and you are correct that following releases will be
much better. Especially since by then, a lot of the major KDE applications will have been
ported to KDE 4.

Developers are the wrong people to ask

Duncan — 2008-07-06T04:16:47+00:00

I believe you are correct, except that I would have called 4.0 an early 
tech preview.

For years, starting back on MS (before I emigrated to a land of freedom; 
I'll continue to compare with them as the majority platform provider out 
there) with IE 4.0 where I ran both public previews, I've been a "bleeding 
edge" beta adopter, but 4.0 wasn't even beta, and certainly not even as 
functional as the MS public tech previews.  It wasn't bleeding edge beta, 
it was ground hamburger early-alpha tech preview, the kind of stuff the 
demonstrate at developer conferences and perhaps send the devs home with a 
conference edition tech preview, but not even public preview level; the 
kind of stuff one realistically isn't even expected to file bugs on, or to 
realistically test, because there's still way more missing than there in 
the first place, and filing bugs just doesn't make sense yet because 
there's more bug than product!

So as soon as I actually had time to try it out and find it wasn't just me 
missing the functionality, but that it actually wasn't there, I dropped 
4.0 like the non-functional bits of bloody ground hamburger flying 
everywhere (when compared to the more conventional "bleeding edge" beta, 
at least) it actually was.  

Don't get me wrong, I'm still a strong KDE user, but for now it's KDE 
3.5.9, not that 3.90 early 4.x preview raw bits of meat flying everywhere 
crap they labeled 4.0.  I've every faith they'll get there... eventually, 
but it certainly wasn't then, and I doubt it'll be what they call 4.1 
(which is more likely 3.95 or 3.98, now).

Of course, the problem was one of PR.  The devs had been talking up all 
this fancy new technology, and everyone was hot to try it with 4.0... only 
what was labeled 4.0 should have been early tech preview as I said -- a 
chance to play with the new technology using still only partially 
developed and working toys, nothing more.  If they'd handled it that way, 
I expect a lot more people would have been a lot happier with it.

But back to the present.  As I said, I expect what is to be labeled 4.1 to 
not even be a real .0 release yet.  Actually, I expect this to be much 
closer to what MS would release as public preview two.  As such, as a 
normally bleeding edge user and happy to be one, I expect I'll actually 
find it usable now, and will actually probably take to it pretty avidly -- 
even if I don't expect it to be proper release quality just yet.  Note 
that I'm still saying "expect".  I'm not crazy enough nor do I intend to 
try "betas of betas", not after the versioning fiasco they already pulled, 
so I'm leaving it alone.  When the final 4.1 (aka 3.98, aka 4.0 public 
preview two, properly versioned) comes out, I'll try it and see if it 
works as I now expect it to.  If so, as a proper bleeding edge beta 
tester, I'll try it and file bugs on it as necessary, and I'll probably be 
reasonably happy running it and working around still not quite there 
functionality.

By extension, what will probably be labeled 4.2 should finally be what I'd 
consider proper 4.0 release quality, something I could honestly but 
cautiously recommend to non-bleeding-edge but still early adopter users.  
And along about (labeled) 4.2.2 or or 4.3.0, I expect I'll finally 
consider it a decent service-pack-1 normal user release.

By 4.4, /maybe/ as early as 4.3, all that hard sweat equity investment in 
all that new technology will be paying off, taking the FLOSS community to 
GUI heights no one, proprietary or freedom based, has ever reached before. 
Yes, I believe it /will/ come, but it sure would have been a smoother ride 
had this versioning and PR fiasco never happened.

Duncan

Stable kernel 2.6.25.10

avik — 2008-07-06T04:05:34+00:00

null function pointers are only exploitable if vm.mmap_min_addr is zero, which should not be
the case on most installations.

I imagine getting 4G references on a task_struct would be hard without root privileges.

Acer's Linpus Linux Lite (Fedora) ultra portable laptop piles the pressure on Microsoft (FSM)

Cato — 2008-07-06T03:07:15+00:00

I know... Somebody needs to tell Linpus that their brand name is disastrously bad.  Analysing
brand names for unfortunate meanings in different languages/cultures is Marketing 101, see
http://www.linguist.com/guidelines_ordering_brand_analysi... for an example of what this
involves.