Slashdot Mirror

when the phone came out, there were a lot of materials about this - a quick search reveals only comments right now, but searching more would turn up much more.

from a comment :
http://lwn.net/Articles/248819/
"Too bad that quite a few components in the Greenphone SDK are proprietary. That makes it almost useless as a developer's toy."

if i remember correctly, they opensourced it when openmoko started or something - but the community desire to hack on it was seriously reduced by keeping sdk closed. imho :)

You can, but it is hard if you can't also see outbound traffic from the other end. In some cases where you know what the output is supposed to be you can do this. udp is somewhat easier to spoof than udp, since you don't need to get sequence numbers right.
Searching for blind spoof will turn up a number of hits. For example:
http://lwn.net/1999/0930/a/tcp-spoof.html

Looks like a troll, smells like a troll, probably *is* a troll.

At the risk of feeding you:

Two examples of exploit lists from different times:
http://www.novell.com/linux/security/advisories/2007_51_kernel.html
http://lwn.net/Articles/118952/

To say that Linux has no security exploits is just plain stupid and naive.

Yes he did. http://lwn.net/2000/features/ESR/. And that was back in 2000! It has been 7 years since, and hardware prices continue to drop.

Maybe this is the year of linux. No really. I mean, for sure ... Totally....

Not exactly:

Actually the EU already protects Wine. Reverse engineering products for the purpose of interoperability is a protected activity in the EU. But don't take my word for it, read PJ's article on reverse engineering at LWN.

Try ".desktop files" linux.

Here's a link: .desktop files and security

Some [misguided] courts have held that because the GPL makes some "offers", the author gives up their rights to pursue copyright violations and is restricted to only pursuing the issue as a matter of contract breach

Anyway, suppose it is ruled to be a contract. You cannot claim statutory damages. However you might be able to persuade the court to order specific performance (they are usually reluctant to do so, but if its just handing over a document they might), so they are forced to open their source.

Otherwise,the developers are entitled to damages to place them in the position they would be in without the breach. How much is that going to be? Enough to replicate any improvements to the code?

Software Freedom Law Center gave some very nice advice on how to wrap new licenses around old code -- let's fork Linux and make the new changes available only under a BSD licence!

We can then ask SFLC for legal advice in case anyone disagrees, right? :)

Here is their advice: http://lwn.net/Articles/248223/

Very interesting! This "recoiledsnake" guy (parent poster), up to this point, was a thinly masked Microsoft apologist:

He was slamming OpenOffice

He was posting a Microsoft explanation for the Windows stealth-update scandal

He was flaming Apple users

He was downplaying an article about a boot sector virus on a Windows Vista laptop

And now, after a long history of Microsoft-centric and Microsoft-friendly comments, he is suddenly pretending to be an expert in Linux kernel matters, giving a deceptive and incorrect account of what happened. (He even got moderated to "Informative". I expect to be modded me down for this - dont spare me.)

Read this if you are curious about the true story of why and how Con Kolivas quit kernel hacking:

LWN.net article

Written by long-time Linux kernel observer Jonathan Corbet.

Could this really be Microsoft PR in action? Is Microsoft trying to plant false grass-roots "history" via such deceptive postings? Seeing that they cannot win via technology in the marketplace, is Microsoft now trying to attack the credibility and integrity of Linux kernel developers?

my friend is the balanced argument. Although I would argue that there are those in your community that *do* feel the lack of two-way contribution is the issue (which I don't pretend to judge).

While reusing the BSD code, even with the more restrictive GPL license is permitted, you're right regarding the (il)legality of stripping the BSD license and associated copyright notice. Which, if anything positive has come out of this whole mess, is much more clear to me and hopefully more in the GPL community.

That said aside from the above example I'm not sure when/where else this has occurred. Considering the reasonably fast response to the unused atheros patch I can't see how if this *is* an continuing issue it can seriously be considered one that wouldn't be responded to.

And you have to remember the "Linux" community, whether you agree with the GPL or not, are (at least technically) people who do believe in the right to protect and license work, or the GPL would be useless. That includes your right and even Theo's. Stealing is not something I think you'd find anyone in the Linux community would condone (or even can, legally).

Anyway, hopefully soon we can move on. I mean it's been fun. Hell, even informative. But it's started getting just plain silly.

my friend is the balanced argument. Although I would argue that there are those in your community that *do* feel the lack of two-way contribution is the issue (which I don't pretend to judge).

While reusing the BSD code, even with the more restrictive GPL license is permitted, you're right regarding the (il)legality of stripping the BSD license and associated copyright notice. Which, if anything positive has come out of this whole mess, is much more clear to me and hopefully more in the GPL community.

That said aside from the above example I'm not sure when/where else this has occurred. Considering the reasonably fast response to the unused atheros patch I can't see how if this *is* an continuing issue it can seriously be considered one that wouldn't be responded to.

And you have to remember the "Linux" community, whether you agree with the GPL or not, are (at least technically) people who do believe in the right to protect and license work, or the GPL would be useless. That includes your right and even Theo's. Stealing is not something I think you'd find anyone in the Linux community would condone (or even can, legally).

Anyway, hopefully soon we can move on. I mean it's been fun. Hell, even informative. But it's started getting just plain silly.

I'm no expert I'm afraid but I'll let I'll share with you what I know. The Linux I/O scheduler (which I believe turned up some time in the 2.6 era) is somewhat separate from the CPU scheduler (although there is a link in priority and timeslices). Thus it was always possible to drag a process doing I/O down by having something else perform enough disk I/O, especially if you are the root user. If you can make a system swap that will hurt things even more (and that's a form of I/O).

The thing to remember is that servicing certain types of I/O need not necessarily use up much CPU time. If a device is capable of doing DMA it will need comparatively little time from the CPU to be serviced (bigger transfers can happen while the CPU is off doing other things as opposed to have the device generating interrupts all the time that the CPU has to service before any more data is transferred because some temporary buffer is full and needs moving). Additionally, certain network drivers are able to do NAPI which can reduce CPU load during heavy transfers. The way that Linux handles interrupts (which have a top and bottom "half") allows the bottom half to happen in a process context (so the heavier part of the processing counts towards a process's timeslice). This is touched upon in on Robert Love's MMCSS entry. However, if you have an important process's I/O queued up behind something less important (and the low priority task is able to generate enough a big enough request for I/O on its timeslice) then the important processes may appear to go slower (effectively its latency will go up due to having to be passed over because its I/O isn't ready) despite having more CPU time assuming the hardware can't satisfy all the requests for I/O quickly enough (imagine big writes to a slow disk with deep queues and the task needing acknowledgement all the data made it to disk).

Depending on which I/O scheduler you picked and your hardware you may be able to alleviate this problem but that's not to say that things can't be improved (or that no one is complaining about the problem).

In short I would imagine the new CPU scheduler impact would be marginal improvement on I/O performance or latency under I/O load. If it was OK before it should still be OK (but bear in mind in memory virus scanning is a special case that I would imagine would make any OS go slower).

And yet the most important performance bugs in the kernel haven't had any updates.
http://bugzilla.kernel.org/show_bug.cgi?id=7372
http://bugzilla.kernel.org/show_bug.cgi?id=8636

I do not understand the fixation on CPU scheduling when there are so many other things that need attention. [Heck, if disk IO performance is so broken, I certainly don't have the guts to try out the new firewire code in 2.6.22 as well and add another variable into my life.]

The OP was suggesting that BSD licensing is bad because it allows embrace-and-extend. My point was that this is not something that can be solved by licensing, and that actually with BSD licensed code there are better chances of compatible implementations (as shown by the TCP/IP example) than with the GPL for example. In fact, even RMS agreed that a less restrictive license (compared to the GPL) is suitable for reference implementation of a standard to gain wider adoptation. Thus the OGG Vorbis reference implementation library was licensed BSD.

Bruce

>The BSD licnese header and author's comments must remain in place. That's all. The only reason to remove it is to pass it off as your own.

Which is what the latest big patch does. It *keeps* the BSD comments, the BSD license text and this and that and instead puts a clarification "this was the previous license" in there. So everybody, stop whining.
URL: http://lwn.net/Articles/247806/

• The patch in question was never official, and was actually rejected
• The license from the very original authors allowed GPLv2 redistribution - The patch submitter DID NOT RELICENSE ANYTHING.
• The BSD License is a permissive one if Theo wants it to be viral he should have made it viral.

It also looks like Theo is trying to push this topic (heck this issue was solved even one week ago when he made his first comments) to get self promotion, it is not like the BSD guys didn't have relicensing of their own

I actually want to puke out of seeing so many guys showing so little problem when someone turns BSD licensed code into proprietary yet get so zealous about GPL'ing it , and tell it rude, etc. Come one, people this is ridiculous! I am so disappointment at the BSD community that I decided to drop my plans to actually try their OS in a close future.

Personally, I want to stick Theo and RMS in a cage and see who lasts longest...

Yeah, Theo is younger and fitter, but Stallman has a katana in imitation of this xkcd cartoon :-).

A little lightening up would be good, frankly.

As noted in LWN, this kerfluffle seems to have been kicked off when "wireless developer Jiri Slaby posted a patch which stripped the ISC and BSD license notices from the source, replacing them with GPLv2 license text. It should be noted that this patch was not accepted into any repository anywhere and never became part of any exported Linux kernel tree. Nonetheless the BSD community exploded in a very public way. It is interesting to compare their public response to this posting with the sort of response they very loudly insisted was their due when they were found to have carried improperly relicensed GPL code in their repository for some time."

Certainly it is NOT okay to remove the copyright notices from BSD material, as long as there's something left in the file that's covered by the BSD license. So, don't do that. But you CAN take a BSD work, combine it with other works, and have the final result as essentially GPL'ed or proprietary. My FLOSS license slide even helps you figure out when you can do that, and when you can't.

But that only covers the legal issues. If there's an existing project that releases something under an OSS license, it's usually better to continue to use their license than to fork off another project under a new license, especially if you're not making many changes. For a lot of reasons.

LWN's article "Relicensing: what's legal and what's right" is worth a look.

That's a good question. It may explain why McVoy used extra-legal channels to try to enforce it; for instance, in at least the cases of Andrew Tridgell and Bryan O'Sullivan, rather than having a lawyer send legal notice to an "offender", he tried to threaten the person by calling their employers instead.

I find the fact that Linus was on board with this (he publicly sided with McVoy in Tridgell's case) pretty distasteful.

As I mentioned the other day, I will not be contributing to Mercurial development for a while. Several people have asked me why.

        At my workplace, we use a commercial SCM tool called BitKeeper to manage a number of source trees. Last week, Larry McVoy (the CEO of BitMover, which produces BitKeeper) contacted my company's management.

        Larry expressed concern that I might be moving BitKeeper technology into Mercurial. In a phone conversation that followed, I told Larry that of course I hadn't done so.

        However, Larry conveyed his very legitimate worry that a fast, stable open source project such as Mercurial poses a threat to his business, and that he considered it "unacceptable" that an employee of a customer should work on a free project that he sees as competing.

        To avoid any possible perception of conflict, I have volunteered to Larry that as long as I continue to use the commercial version of BitKeeper, I will not contribute to the development of Mercurial.

        As such, Mercurial can stand entirely on its own merits in comparison to BitKeeper. This, I am sure, is a situation that we would all prefer.

And, as I noted in my other post, if McVoy ultimately failed to suppress Open Source SCM development, it wasn't for lack of trying.

Ah, it was Mercurial, not Monotone. Larry McVoy threatened Bryan O'Sullivan into leaving the Mercurial project.

What is even sadder, is that there wasn't really any "engineering" involved, just a little common sense.

http://lwn.net/Articles/132938/

Tridge telnetted into the BK port and typed "help," getting back


        help
        ? - print this help
        abort - abort resolve
        check - check repository
        clone - clone the current repository
        help - print this help
        httpget - http get command
        [...]


*wow*

You are correct that the GPL is a license and not a contract. However, that actually furthers my original point. From http://lwn.net/Articles/61292/ , quote by "Professor Moglen":

"The GPL, however, is a true copyright license: a unilateral permission, in which no obligations are reciprocally required by the licensor. Copyright holders of computer programs are given, by the Copyright Act, exclusive right to copy, modify and redistribute their programs. The GPL, reduced to its essence, says: 'You may copy, modify and redistribute this software, whether modified or unmodified, freely. But if you redistribute it, in modified or unmodified form, your permission extends only to distribution under the terms of this license. If you violate the terms of this license, all permission is withdrawn."

So the original copyright holder never has any obligation at all to the GPL. He can do whatever he want (as long as he is the sole owner of the original code).

If I distribute a program I have written myself and include the GPL license, but refuse to give out the source code, I am doing nothing wrong. I already have distribution rights to the binary, so I don't have to agree to the GPL. At the same time, anyone getting a hold of the binary, can't legally redistribute it because they don't have the source code, so they can't furfill the requirements needed to get a license for redistribution.

"I'm very curious to see if the GPL is even a legally valid document. How can you agree not to sue "somebody?" With commercial software there is at least an implication that the license has been granted to a specific customer, not "everybody in general.""

GPL is also only granted to a specfic person. To be specific, the one who is planning to redistribute the program. If you are just using the program, you aren't actually operating under the GPL license. This however doesn't really matter. Licenses are just a grant to the user so that he can do something he otherwise legally couldn't. Because it isn't a contract, there is no need to target it to specific individuals.

What I question more are EULAs. If they aren't contracts, but only licenses, their only power should be to allow the user to do something he couldn't otherwise do (in exchange for possible restrictions). Agreeing to an EULA should however not constitute a contract.

Even if I click the yes box in agreement to an EULA, it shouldn't affect me as long as I am only doing things that I can legally do without the EULA. It is only if I need to do something that is illegal, but granted by the EULA that it should start to affect me.

This must be why we're all using tux2?

Please take a look at Linux Device Drivers, Third Edition. It's available for free but you of course will be purchasing it (you only mentioned it had to be free - not that you would be using the free version if there were multiple versions available).

I'll be expecting to see your name popping up on the Linux Kernel Mailing List in a few months announcing fixes and new features for my Intel, AMD/ATI, Via and NVIDIA graphics cards (some of which you will be reverse engineering). No need to thank me (you may also need to find a good book on X).

Unless they pull an Intel and release/fund Free drivers for their graphics chips, for me it's Intel for ease-of-use and NVidia for performance. I've lost faith in them.

If the quote from the Linux kernel summit is true, you may be right: AMD to open up graphics specs

Now I wonder how nVidia will handle this. :)

Or you might want to try this: AMD to open up graphics specs

Then maybe you are interested in this?

Yeah, I know, sounds too good to be true. But last time I checked, April 1st had already passed.

It was announced today at the Linux summit they will open up specifications for all graphics cards, and release a 'reference'/minimal open-source driver for all cards.

More here: http://lwn.net/Articles/248227

Ding, and we have a loser. Check for example this.

It's fairly well known that large writes to the filesystem can cause huge read delays.

This seems to be aggravated by a number of conditions listed in the links posted by the parent post, but it's also aggravated when using ext3 and ordered data journaling as well (which is the default on most systems).

There is some work being done to reduce the huge latency in reads that can occur during heavy write loads with the "per device dirty throttling" patchset. Initial results look very promising.

LWN article: Smarter write throttling
per device dirty throttling -v8

This patch set seems to hold a lot of promise in being able to fix this problem, but I'm not sure what the latest status is or what kernel it will make it into. It could make it into 2.6.24 at the earliest.

It's fairly well known that large writes to the filesystem can cause huge read delays.

This seems to be aggravated by a number of conditions listed in the links posted by the parent post, but it's also aggravated when using ext3 and ordered data journaling as well (which is the default on most systems).

There is some work being done to reduce the huge latency in reads that can occur during heavy write loads with the "per device dirty throttling" patchset. Initial results look very promising.

LWN article: Smarter write throttling
per device dirty throttling -v8

This patch set seems to hold a lot of promise in being able to fix this problem, but I'm not sure what the latest status is or what kernel it will make it into. It could make it into 2.6.24 at the earliest.

Sounds like Linux isn't the only OS that could benefit from network channels ..

To the best of my knowledge, you are correct that every Git user has the entire history.

This is really a non-issue, though. Storage is cheap and the history doesn't take up that much space.

The 2.6 kernel takes about 285MB and the entire 2 year history is about 187MB. The initial release was in 1991 - 16 years ago. Assuming 187MB every two years (which is certainly a gross overestimate) that's still less than 3GB. Not exactly small, but not obscenely huge either by today's standards. But it's not even that bad. You can get the entire kernel bitkeeper history here in under 200MB (which is still comfortably smaller than the kernel, itself).

The repository size wasn't even the reason that Linus gave for not importing the history. If memory serves, I believe it was more of a technical issue of correctly importing the history from bitkeeper and patches.

Similarly, when you hear that the GPL is viral and can force proprietary code to become GPL, which a couple of lawyers have been saying, you'll know that isn't true. If you steal GPL code, you can expect an enforcement action. But this action can only be enforcement of a license, not a contract, and a forced release under the GPL can't be imposed on you under copyright law. It's not one of the choices, as Professor Moglen has explained. You do have a choice under the GPL: you can stop using the stolen code and write your own, or you can decide you'd rather release under the GPL. But the choice is yours. If you say "I choose neither," the court can impose an injunction to stop you from further distribution, but it won't order your code released under the GPL. Your code remains yours, as you can see, even in a worst case scenario.

If I give you my GPL'd code, I am only giving you a license to my code, not a contract (estoppel (which I presume is the case you are arguing) is under contract, not licensing law). I would not be able to revoke a contract, but, as an author, I can revoke a license.

On "there's no freedom to deny freedom to others"

He used the word troll, and I repeated it. We are talking about legal affairs, how you "feel" about things is irrelevant (which of course is similar to saying "I feel my code works"). That definition of the GPL is imprecise at best (it implies things that the GPL does not, and cannot do) and incorrect at worst (in the case of an author revoking the code, it is incorrect). It means that authors do not have the right to license their copyrighted material as they please. Copyright law alone means that _only_ the original author has the right to license their work, and as long as they do not place it in the public domain, no one can change the license.

What the GPL does is force distributors to distribute code as well (with the BSD license, they are only required to give a copy of the license with the relevant author's details on it, but notice that in both cases the code is available, the only difference is that you may have to look harder for the BSD licensed code). The other part (as mentioned in the link and quote) is what you must do to statically link your code to GPL licensed stuff (this is copyleft, what the BSD license lacks). You still have the option not to GPL your code, but that means that you lack distribution rights.

Again, this argument isn't anti-GPL, it is only an argument that there is no way to "sudo copyright_law" (aside from being in government and changing copyright law, but since most don't have this ability it is irrelevant), no matter how convenient it would make things. An author can revoke the BSD license on their code too, in fact, I think everything I've said is just as relevant to the BSD license as it is GPL. And that is where I think you are mistaken, you assume that I'm discussing the negatives of the GPL, when I'm really just trying to clarify copyright law. I've reviewed many licenses to ensure that I'm getting what I want (and can have) out of them. All I will say on the license debate is that I believe in choosing the right tool for the job

Coz he doesnt like weather forecast. Never have and probably never will...

Please keep in mind that Red Hat is _part_ of the community. Not only do they contribute a tremendous amount to kernel development, but their employees are extremely active on mailing lists, blogs, IRC and elsewhere interacting and helping out the "community" in addition to their paid support.

Dunno. Consider the comments on this LWN article from May 2003 , though.

A license may be included in a contract; neither GPL or copyright law itself are. Microsoft vouchers are inducement and secondary infringement, it'd be hard to claim inaction here.

Red Hat developers made almost half of the kernel patches? Well, that's stretching it a bit.

Luckily, Jonathan Corbet did two excellent pieces on this matter on LWN:http://lwn.net/Articles/222773/ and http://lwn.net/Articles/224244/. These show that Red Hat is there in the top with Intel, IBM, Novell and the Linux Foundation. FYI

Red Hat developers made almost half of the kernel patches? Well, that's stretching it a bit.

Luckily, Jonathan Corbet did two excellent pieces on this matter on LWN:http://lwn.net/Articles/222773/ and http://lwn.net/Articles/224244/. These show that Red Hat is there in the top with Intel, IBM, Novell and the Linux Foundation. FYI

This "clearing" the HAL drivers is old news
http://lwn.net/Articles/209472/
This was done in 2006.

I was searching for the same thing (I wanted to test a crash Mac users experienced with an cross-platform app, but I don't own a Mac.), but I found nothing usable.

There's "darwinux" (http://lwn.net/Articles/229088/), but this far away from being usable.

Have you investigated the CFS code? There is an interesting discussion about CFS internals over at LWN that seems to contradict what you say:

http://lwn.net/Articles/242992/

There Ingo explains that the "sleep events" mechanism you mentioned survives in CFS too, so you get both "fairness" and "sleeper fairness".

I read the post. There's a big difference between sleep-duration (to which you refer) and sleep-frequency (to which I refer). Basing decisions about sleep-duration is fine, and is equivalent in every respect to basing decision on runtime (as the two are complementary). The O(1) was largely based on sleep-frequency. In contrast to what the lwn post claims, the two schedulers have a lot in common.

Linux doesn't support that, as far as I know. There are variables you can tune though. More on this later.

Something like that is very risky. Where as a filesystem can be used or not, and the code is only hit when accessing it, the scheduler is used constantly. If the scheduler could be switched at runtime, that means that either you have to have some kind of if statement on every scheduler entry point, or hide it all behind a pointer and a structure. Either one isn't as efficient as just having it hard wired in. You also have the complexities of being able to hand stuff off from one scheduler to another. Also, debugging get much harder (you have problem with slowness X, now which of the 3 schedulers are you using? Which version? What are the variables set to?).

As for selectable at compile time, that means you have a have a well designed interface that lets you swap things out. That means it either has to be generic, or would favor one scheduler to the detriment of others. Sometimes this tradeoff is acceptable, sometimes it isn't.

Now my understanding on this is that Linux doesn't support plugging in full schedulers. There were patches for that a few years go. Linus and others (Ingo especially, I think) said no, and the patches never made it in. Recently a system was developed that would allow a part of the scheduler to be plugged in. This way it could be better tuned for different workloads, without the full detriment of a full pluggable scheduler. This was done recently, and they were called out on this flip and explained quite well how they were a little hard, and this was a little different.

Go read LWN's kernel pages. They talked about this in the last month or so, so it should be available to non-subscribers by now (although you should subscribe, they're great).

usb drives: probably not a problem. A color laser printer that works: check out http://www.openprinting.org/ first! Shop for a supported printer; e.g. currently (27-07-2007) from brand "HP" I see color laserjet 2500 and higher rated as "perfectly", model 1600 and 2600n as "mostly" and model 1500 as "paperweight" so YMMV.