Slashdot Mirror

Care to rebut this explanation?

So you don't have LRW support on Linux.

Just to be clear, the "well known" problems with loop-AES were shared by dm-crypt, and they were only well known because the loop-AES author acknowledged them loudly and fixed them while Clemens kept shouting "no no no there is no attack and you are stupid".

http://lwn.net/Articles/67216/

The scheduler in Linux has just been ripped out.

...[involving] numerous strange computations involving a number of magic constants; it is difficult to understand, much less improve. --Linux Weekly News

A better url:
http://lwn.net/Articles/101709/

hey wait TTY layer ...any takers? please :-)

Here you are.
An article with details, and details from the patch itself.

http://lwn.net/Articles/229984/
http://lwn.net/Articles/229096/

Here you are.
An article with details, and details from the patch itself.

http://lwn.net/Articles/229984/
http://lwn.net/Articles/229096/

There for you, help yourself.

BTW in short plain english, it adds some voodoo stuff to struct page, removes a lot of metadata cruft from the slab allocator, adds lesser and simple locking after removing most of locks which are not required because of the changes in the cache layer.

So if you are running your kernel on a huge farm of processors of the order of thousand(s), you ll find a remarkable memory saving, which is a big overhead in slab allocation.

HTH

Dude, Google is your friend: http://lwn.net/Articles/229984/

Ah. Thanks for explaining that. I guess, were I hard-working enough to read and ACK patchsets for the kernel, I'd say that the interfaces are documented in the /Documentation directory of the source tree and in the C code itself. Writing a standard interface would only be an addition to the /Documentation tree, especially with Corbet/Kroah-Hartman/Rubini ("Linux Device Drivers", O'Reilly) being available at lwn.net (http://lwn.net/Kernel/LDD3/) under the Creative Commons 2.0 Attribution ShareAlike licence. Linux Device Drivers may cover 2.6.10, but any changes to the kernel over the past 18 months/two years are documented also at Linux Weekly News.

Is something like this what you mean?

http://lwn.net/Kernel/LDD3/

Never messed with OO, never a reason to. HAVE messed with the kernel in years past, which used to be a lot more necessary than it is now. Most of the messing around, which I consider casual, has been in driver space (USB and ethernet), because that is the space that affects me the most - if your hardware doesn't work you have a vested interest in getting it to work. Sometimes it's as simple as adding a new PCI deviceID, others can be a lot more "intense." Getting involved is easy - send a patch the the LKML and the module maintainer.

So how many people send in patches to the Linux kernel? Well, this article looked at a recent one-year time frame and came up with almost 2000 authors had changes accepted. If you look total all-time numbers, I would bet it's probably Well over 10K.

As far as messing around with open source in general, it's been hundreds of applications / utilities / etc. going WAY back to the days of "Adventure" on the mainframe via model 33 teletype. XYZZY people!

Does anyone know of a page that charts relative contributions (hopefully some way better than kLoC, but that would be better than nothing) of different Linux distributors?

It will slow it down, perhaps making it more cumbersome to use until an alternative is developed, but it won't kill MythTv. Far from it.

And, as a longtime MythTv user I'd cheerfully cough up $50/year for access to the data. Zap2it has been reliable and accurate for me, and I'd support them. But then I'm weird - I subscribe to comics and journals.

Detailed understanding requires a whole bookshelf, and several years hacking away at a couple of drivers, but here is a good start.
http://lwn.net/Kernel/LDD3/

It's not too suprising, although Microsoft seem to have had a few victories recently these are very small. Who're Novell, Xandros and Linspire anyway? Small fry really (with the possible exception of Novell, who've been badly burnt by the whole experience). Also remember SCO managed to sell a few of its spurious 'licenses' before IBM made mince meat of them in court. Their claims were even more daft than those made by Microsoft (remember copyright vs. patents).

As Red Hat pointed out in their excellently thought-out advert:

1. First they ignore you
2. Then they laugh at you
3. Then they fight you
4. Then you win
5. ...
6. Profit!

Ok, so I added the profit bit: no /. list should be without it. :)

Ask and ye shall receive:

http://blog.washingtonpost.com/securityfix/2006/03 /when_macs_attack.html

http://lwn.net/Articles/222153/

http://www.networkworld.com/community3/?q=node/534 4

http://blogs.securiteam.com/index.php/archives/304

http://www.shadowserver.org/

I can continue for pages and pages if you wish. You know, search engines are useful tools at times ;) Now granted, most of it comes from exploits in 3rd-party apps, such as Apache, PHP, SQL, etc. But...knowing this, and how there are botnets running with Apache priviledge levels.....kind of dumps that whole "don't run as root in *nix" argument right into the toilet. As long as people are people, they can be socially-engineered to offer up their passwords for whatever reason (I'm looking at you, OSX users). Relying on a popup password entry box for security is just as silly as allowing a Windows machine to sit un-patched on the internet.

I am actually quite surprised that more OSes don't have some sort of application firewalling/sandboxing built into them, instead of relying on concepts like UAC or root permissions that are worthless if all it takes to bypass them is someone typing a password into a popup box, clicking Allow (and how many people do we know that use blank or short, all alphabetical passwords, hmmmm?), or running insecure application software that is always accessible via the internet.

Not a lot, but there was one very critical last year that had remote root capabilities:

http://lwn.net/Articles/176596/

Except this time they're doing it directly, rather than through their shill:

http://lwn.net/Articles/73592/

AppArmor's unique change_hat confinement can block this

change_hat is not a feature ... it's a horrible bug, real security solutions like SELinux have explicitly rejected bugs like this. Please don't pretend you've done something useful.

Any network client (Firefox, Thunderbird, Gaim/Pidgin, etc.) can be compromised by remote vulnerabilities and malicious content, giving the attacker total control of your user account. AppArmor confinement of your clients makes it safe to e.g. IRC to strangers.

Do you plan on shipping Firefox with a useful profile that will stop it doing this? This is on the roadmap for SELinux, and they can do useful confinment because they aren't limited to pathnames ... and guessing and hoping based on trial runs. Also have you at least worked out why AppArmor thinks thunderbird needs setuid()?

It was a while back now but Sys-con allowed Maureen O'Gara to publicly attack PJ of Groklaw fame. I wish I had realized what I was clicking through to before viewing the article. Being bombarded with the ads from their site just helped enforce my dislike of their services. To Sys-con's credit, they did drop O'gara, I guess.

Keep in mind that most of the (tech) people hired by Mandriva, Linspire and all are packagers and not developers (I said most, not all). Look at Who wrote 2.6.10 to get an idea of the companies that contribute to the Linux kernel (I assume the other pieces of software are roughly similar). Outside of RedHat, the only other distro you see there is Novel with a contribution around 3%. No way in hell a bunch of distros with MS deals can fork the entire GPL codebase. Without the rest of the community, they wouldn't be better off than if the software was closed source to begin with. There are many things to worry about with MS, but a "giant GPL fork" is not one of them.

Git might suck badly if you have ... or a centralized repository, a different development model, or simply want UI tools & IDE integration.

Git works perfectly well with a centralized repository. This use case is fully supported and actually has some unique support in the git-hooks. However, its discouraged socially.

I am not sure what kind of model git, darcs, mercuirial, bazaar, or monotone couldn't satisfy. They all scale from one person to many (albeit speed concerns with some). They can be used in a variety of ways. The only really annoying part I've ever found is the lack of support for empty directories, but that's what .anchor files are for, I guess.

Git actually comes stock with some of the best UI tools I've ever had included with my version control system. Seriously. Go take a look at gitk and check out git-gui.

As for IDE integration, a google search will show you that's already falling into place, and it took me all of 2 days to get work to play nice with TextMate (my editor of choice).

>If it weren't for RMS, Moglen, the FSF, and now the Software Freedom Law Center, all you "open-source" folks would be working for Microsoft or some other proprietary software developer.

There are plenty of evil proprietary software companies inserting evil code into open source projects.

Its going to freak us all out eventually until our brains explode like in 'the scanners'.

http://lwn.net/Articles/222773/

Top lines changed by employer
(Unknown) 66154 19.0%
Red Hat 44527 12.8%
(None) 38099 11.0%
IBM 25244 7.3%
Astaro 15306 4.4%
Linux Foundation 13638 3.9%
Qumranet 12108 3.5%
Novell 11930 3.4%
Intel 11652 3.4%
SANPeople 9888 2.8%
NetXen 9607 2.8%
Sony 8497 2.4%
Broadcom 8349 2.4%
Tensilica 8195 2.4%
Nokia 5581 1.6%
MontaVista 4394 1.3%
University of Aberdeen 4324 1.2%
LWN.net 3975 1.1%
Secretlab 3370 1.0%
HP 3211 0.9%

You know, companies are mostly free to make deals with other companies provided no laws are broken.
Microsoft is free to use GPL'd code, provided they follow those (GPL, LGPL) agreements.

OTOH, if **any** company doesn't follow the agreement - GET THEM!
Too many of them - http://gpl-violations.org/
Linksys being the most famous: http://lwn.net/Articles/51570/

Personally, I'd love to see Microsoft found guilty of violating the GPL/LGPL, but I know how hard they work to ensure that doesn't happen - at least a few years ago they worked really hard.

OTOH, OSS developers should also respect when a company decides they don't wish to be part of any OSS-based licensing. Personally, I avoid doing business with those companies, unless absolutely necessary and I keep the amount of business to the minimum possible.

Philips decided to use the compression because they make the camera. Nemosoft wrote the driver. From what I can tell, you need compression to get a decent frame rate/resolution on USB 1.0. Philips worked out a way to compress efficiently in hardware. Since this the only part of the webcam which is non obvious, Philips wanted to make money out of it by licensing, or maybe they licensed it from someone else. For whatever reason, they didn't want to release source code to the decompressor. They did let Nemosoft get the details under NDA and write a binary only plugin for the driver.

Says who? Code under the GPLv2 can be linked with a lot of other code; all that matters is that the licenses are compatible.

Right, but what does "compatible" mean? The answer is that "compatible" means that the other license is "more Free" than the GPL, by which I mean that it imposes fewer restrictions on redistribution. The reason for this is the following clause in the GPL:

"You may not impose any further restrictions on the recipients' exercise of the rights granted herein." (Section 6)

For example, the original BSD license is incompatible because it contains an advertising clause -- an additional restriction -- while the new BSD license is compatible because that clause was removed. The Affero GPL is incompatible because it has additional restrictions about programs distributed as web services. The CPL is incompatible because it requires the licensing of any relevant patents.

I have seen no indication that GPLv2 and GPLv3 are incompatible.

The GPLv3 will be incompatible with v2 (again, without the "or later" clause) for the same reasons as the Affero GPL and the CDL: it will contain additional restrictions regarding patents and distribution as a web service. Also, I'm not sure why you've never heard of this; not only does one person say that it's "always been known", it's even in the FSF's FAQ (see the "compatibility matrix"!

He didn't say Linux was dead. He said the free software movement was dead.

And he's right, if you don't think that most of the work done on the kernel is bought and paid for by commercial entitites, you're just burying your head in the sand. LWN did a story on it.

How does this relate to the Open Invention Network? They are supposed to hold a large number of very high profile patents, and go after any company that tries to use patents to go after users of various high profile open source components, including the Linux kernel. (See http://lwn.net/Articles/178673/ for more information)

• Microsoft - Conspiracy theorists find a way to blame Microsoft for every problem in Linux. This time they point out when Microsoft decided to use a vendor's chip in the XBox consoles or chipset vendors puts DirectX 8.0 support you don't get specs any more.
  
• ??? - Patents and fear of competitors or patent scumsucking companies bringing infringement. Vendors claim releasing chipset docs to the public may make it easier for these things to be found; however, most X.org developers have no problem signing suitable NDAs .
  
• Profit - Graphics card manufacturing is a very competitive industry, especially in the high-end gaming, 3-6 month development cycle, grind-out-
  as-many-different-cards-as-you-can. Quake 3 speeds are spotted in binary drivers any way and it doesn't explain fglrx which are some of the most unsuitable drivers for gaming on Linux.

Secure DNS isn't an accepted mechanism, and has some issues. SSL is still a better option IMO.

And yet, a TLD isn't foolproof when any fool can have a malware that render the client endpoint in non-trustable (e.g. tainting completely the web browser and or TCP/IP stack).

Newer linux kernels will support "dynticks" that might slightly extend a laptop's battery life.

How come there is still no support for the Microsoft Natural Ergonomic Keyboard 4000, as they call it? It's the best "broken" keyboard out there and one of the most comfortable ones I've ever used. Patches have been submitted multiple times, and seem to be maintained... No love for this hardware.

First couple of Google hits:

http://lkml.org/lkml/2006/8/3/80
and
http://lwn.net/Articles/194015/
or
http://gentoo-wiki.com/HOWTO_Microsoft_Natural_Erg onomic_Keyboard_4000
or
http://doc.gwos.org/index.php/Microsoft_Natural_Er gonomic_Keyboard_4000

And no, I don't want to recompile my kernel.

A tickless kernel gives the scheduler much finer control, and down the line will probably improve performance.

http://lwn.net/Articles/223185

There's some folks working on scaling, too. ;) I wonder where I'll get a 4096 CPU machine, though...

I appreciate your position and I've argued it myself and when I finally upgrade (my 5yo 2GHz Pentium Linux box works better than most modern XP machines, so there's no reason to upgrade other than KVM), I'll move to an Intel Motherboard that supports open source 3D acceleration.

That being said, you're making three big assumptions:

1) The biggest one is that users are too stupid to appreciate the value of open source drivers. They might be uninformed or naive or lazy enough to buy proprietary hardware initially or have a legacy system like myself, but sooner or later they will get hit with one of these situations.:
- Their drivers will not be supported any more (see http://lwn.net/Articles/229838/ ) turning them into expensive paperweights,
- Or that the driver is supported but removes a feature you depended on (see http://reviews.cnet.com/4531-10921_7-6651889.html )
- Or that the driver adds an annoying feature (http://news.com.com/TiVo+extends+ad+features/2100 -1041_3-5792956.html)
- Or that the driver has a bug that won't be fixed soon so you have to live with it until they get around to fixing it. (http://arstechnica.com/news.ars/post/20070206-878 4.html)
- Or that all open source drivers contain a feature they're salivating over but closed source drivers don't because the company hasn't gotten around to implementing it yet. (e.g. NVidia support for XGL was extremely slow in coming, or Rockbox versus all the proprietary music player firmware)
- Or the manufacturer installs a rootkit that threatens the security and privacy of your computer (http://en.wikipedia.org/wiki/2005_Sony_BMG_CD_cop y_protection_scandal)

When any of these happen, the user will have to face the music and the next time they upgrade, all things being equal, they'll pick the open source version. If they've been bitten bad enough, they might even go for the "Ultra-free version of Gutsy Gibbon" (that goodness it'll exist) so they don't accidentally select proprietary firmware (or at least be aware of how exposed they are to potential threats so when they upgrade, they'll know what to change).

2) You're also assuming that people who are considering Ubuntu already have computers that only needs free drivers and they have the knowledge to know why things don't work and either know how to choose hardware that does work and choose to throw out their old card in favour of a free card or at minimum know how to install non-free drivers to get things to work. If new users don't have a clue how to do all of these, they'll just give up and you've lost a potential Ubuntu user. Without more Ubuntu users, case (1) will not happen so no additional pressure on manufacturers will happen.

3) You're assuming that even if the user is keen on learning so as to avoid the problem of (2) that they'll stick around long enough to realize that all the pain associated with Linux is dwarfed by all the gain Linux has to offer. Like it or not, all operating systems have a learning curve and all have annoyances that you tend to accept and forget about once you experience the benefits of the OS. If you can get people past the pain-pleasure break even point, you'll keep them. If you can't, they'll go. As with (2), this means that case (1) will not happen so no additional pressure on manufacturers will happen.

The problem is that Nokia considers GNU/Linux tablets to be unsupported abandonware only 1.5 years after introduction. The tablets are loaded with proprietary and binary-only drivers and software, which means once official support goes away, you're left with a very expensive paperweight. Linux Weekly News reported on this just this week.

You wrote:
"How much have they changed linux to optimise their operations? Who would benefit from the same patches? Nobody knows."

(Disclaimer: I work there.)

Seems like we contribute quite a bit back.

The kernel used in the Google Search Appliance can be downloaded from
http://code.google.com/patches.html

Also, here are a couple ongoing, open source, projects at Google to enhance the Linux kernel:
http://lwn.net/Articles/199643/ - kernel containers - for lightweight virtualization
http://code.google.com/p/zumastor/ - filesystem snapshots, remote replication

You can see quite a few patches here:
http://groups.google.com/group/linux.kernel/search ?q=google+patch&scoring=d

Heck, the guy two desks down from me is working on removing the command line
length limit; that's something Google needs internally, and he's going to
great lengths to get his code upstream (making it work in hppa, for gosh' sakes...)

Google submits a significant number of changes to the mainstream Linux tree, as shown by (among other things) this recent lwn.net article. For 2.6.20 they landed up rougly between Intel and HP ... both of whom have much more reason to be working heavily on the kernel, especially on the server end of the market.

Of course, there's no way of knowing if they maintain whole new optimised subarches, special file system drivers, etc in-house... but I suspect that anything they do keep private is mostly not released because it won't be very useful outside Google. Perhaps they're limiting access to things that'd only be useful to their direct competition in immense data warehouses - but y'know what, I don't care myself. I wouldn't be surprised if the kernel folks would reject any excessively specialised or over-complex changes anyway.

That said, as you pointed out little of what they do is releases as OS. More than most companies (at some) - including some nice search and data handling tech and some handy libraries - but hardly the crown jewels. I for one do not find this overly troubling.

I do, however, share your spine-crawling feelings with regards to the DoubleClick association. I've never been fond of DoubleClick at the best of times, and don't like the thought of their data being combined with Google's.

The problem with running 64-bit Linux is you wind up with what almost equates to two Linux installations. This is because you wind up having both a 64-bit and 32-bit environment, otherwise you can't run 32-bit software.

the biggest problem - as I understand it, at least (if I understand incorrectly, then I guess the people who advocate them have more work to do to educate the masses), is this..

With a BSD license, I can include a piece of open source code in my project, compile it, release it in any which way I want, and be done with it. I *can* contribute back if I change any of the code in that open source code, but it is not required of me.

With a GPL license, if I include a piece of open source code in my project, compile it, and release it in any which way I want, I...
- need to make not only the original open source code available
- but also the source code of my entire project
- whether I make changes to the open source code or not

The only other license that is a mix of both, is the LGPL, where I can use the source code in my project as long as it compiles to its own library (say, a DLL on Windows), and I tap into that library. I still have to release the source code to that library, including any changes I make to it, but my entire project doesn't automatically become GPL.

Given that libraries aren't always possible, and that not too many developers choose LGPL (it's mostly either GPL or BSD - dozens of other flavors to suit authors' specific demands notwithstanding), BSD code - for many developers - is 'better'... to that developer, not to the end-user, per se. Though one may always think otherwise: http://lwn.net/2001/0301/a/rms-ov-license.php3

In that case, I think you may be surprised by this.