Slashdot Mirror

One option worth looking at is Transifex. It's being very actively worked on, with the release of the next version imminent. Also, a hosted version is planned, so you eventually won't even need to maintain a server to run it on. It works with the big five FOSS VCSes, and the new version will be able to crack open tarballs as well. The Fedora Project has been using it for about a couple of years now, with great success.

I work in a large ISP, and this is the way we manage updates for the various Linux platforms we use. Quite simple, really. You can build tools that help: diff between the downloaded updates and what you have in your own repository, and mail you the ones that you are not using. I find lwn.net's security pages useful in keeping track of what security updates matter to us.

In distros like Fedora, which include utrace, you already can use systemtap to probe both the kernel and userspace without problems (sure, it lacks the "final polish" of dtrace, but all the hard has been done)

Really? Are there probe points for userspace method entry and exit? Is there a way for dynamic languages to add probesets like the dtrace jvm agents? I haven't seen anything like that. Got an example?

I'm looking around a bit, and this LWN article on utrace doesn't make it clear to me what actual functionality exists today.

I didn't see full details in the linked AP article, but these schemes almost always get it backwards.

Content is ubiquitous. They need to look at charging for something other than content. For example, charge for timeliness. In other words, put up a paywall that only surrounds the latest week or two of articles. And I don't mean AP reprints, I mean timely local news coverage and opinion that isn't available anywhere else. Let people who want that information as soon as it is available pay a premium, but eventually migrate it all out to the free world. That way you build up an portfolio of work that is both useful to people do research on the net and gives a very good idea of what people will get for their subscription money.

They might even take it a step further and sell a subscription tier that does include hardcopy delivery in addition to electronic, like the WSJ and Consumer Reports do.

The Linux Weekly News works like that - you want this week's news this week - that requires a subscription, but if you want last week's news or last year's news, that's free.

If an attacker can run code as your user account, then they can insert alias sudo=evilpasswordstealingsudo (as well as alias su=evilpasswordstealingsu) into your .bashrc and wait for you to start a new shell and run one of those commands.

Basically, if an attacker gets local access to an account that is ever used to privilege escalate to root, then the attacker can get root. And even if not, there are frequently local root exploits (like a recent udev bug) that can escalate ordinary user privileges to root privileges. You should always assume that once an attacker has some access to a machine, that they can root it; treat any kind of remote-code execution exploit as if it were a remote root, and treat any kind of privilege escalation exploit as a remote root (since if one exists, there's a high probability that the other does too).

No wait, make that 2000.

Don't jump to your guns and proclaim ESR's clairvoyant genius, though. In 2000, he said to LWN "I believe that will happen probably within five to six month from now." I hope for his sake he didn't sit and wait it out...

> Buying laptops with XP Pro rather than Home got difficult enough...

Buy professional grade laptops instead of home stuff and it isn't at all hard to find. HP and Lenovo will fix ya up with an XP Pro preload. Of course you have to pay for Vista Business to get the upgrade rights for XP Pro. But Vista Business is the roughly similar product to XP Pro so it isn't totally unfair.

> Linux returns of netbooks have been far higher than Windows, from what I've seen.

Quit spreading this debunked FUD. See LWN's link to one of the debunkings.

> Assuming of course that the netbook market doesn't go the way of the PDA market.

Too true. My prediction? The current netbook market will be dead in two years, replaced by subsidized crap from the 3G carriers in teh same way pretty much every PDA morphed into a cell phone with a contract. But perhaps the really cheap ARM netbooks will survive since they will be too cheap to subsidize at the current 3G rates.

Realtime priority != realtime patch.

Yes, that's true. However, realtime priority without realtime patch is pretty damned non-realtime. Otherwise, we wouldn't need a realtime patch.

If you've got at least a dual core CPU, a stuck RT process shouldn't bring the system down. It'll use up one core, but you'll still have another to kill it.

Well, why don't you go test it? In the meantime you can read more about the issue.

I don't know about Unix, but Linux servers can definitely be compromised and added to botnets. I recall an article that suggested that compromised Linux servers were typically used for the C&C servers for a lot of botnets. I couldn't find the article after googling, but light googling turned up similar articles such as this: http://lwn.net/Articles/222153/.

To address your second point, its true that its foolish to say that market share is the only point that matters. But its also foolish to say it doesn't matter at all. In reality, malware authors want to get the maximum penetration, so the equation comes out to(installed base * probability of infection). You could have the most insecure OS in the world, but if only 2 people are using it, no-one is going to bother. Likewise, you can have 99.99% market saturation, but if its incredibly difficult to penetrate, then no-one is going to bother.

But when it comes down to it, the OS you're running is only as secure as its stupidest user. There's pretty much no way to stop a user from installing malware along with their funny cursors and warez, short of not giving them root/admin (which, if its their computer, is not really feasible).

Oh, by the way, the vast majority of those MSSQL attacks are SQL injection attacks (stupid developers, not the product), combined with poor database permissions (stupid DBAs, not the product). IIS has been incredibly secure since version 6, and Windows Server is OK out of the box and getting better.

As an honest question (from someone who, not that it matters, runs both slackware at home and xp at work), what's with the obsession with boot time? Can anyone explain why the free software community is so obsessed with this metric? I understand that embedded devices are better when they boot immediately - nobody wants to have to wait to make toast - but to boot a computer?

Boot time is the only time the computer is on when you can't switch to a browser while waiting for it to do something you want done, but aren't interested in the process. You can do that with copying, torrenting, uncompressing, compiling, encrypting, etc, but not boot.

Also, because you shouldn't have to wait.

Don't most people just sleep or hibernate their computer these days anyway?

I dual boot Gentoo and Vista. And ditching either one is not an option.

It really sucked when most of the users could never have more than one application using audio simultaneously.

I have been actively using Linux way before PulseAudio first appeared, and I don't recall that being a problem. In fact, rather, there were always too many solutions, from dmix in ALSA to sound daemons such as arts and esound. Why add another one to the list, especially if it's not good enough yet?

If you have a problem with pulseaudio, please consider filing bug reports.

While it's definitely advantageous for users to file correct bug reports, not all of them understand the procedure, nor should they be made to. And, of course, developers shouldn't just ignore criticism under the excuse that it's not properly framed as a bug report.

For staters, how about this?

...except they aren't using mod_gzip/deflate. At first I thought you browsed the web RMS style and maybe wc* didn't support compression** and you were just getting what you deserved***, but then I checked in firefox and lo and behold:

Response Headers - http://www.theglobeandmail.com/blogs/wgtgameblog0301/

Date: Fri, 27 Mar 2009 23:39:54 GMT
Server: Apache
P3P: policyref="http://www.theglobeandmail.com/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa TAIa PSAa PSDa CONi OUR NOR IND PHY ONL UNI COM NAV INT DEM STA PRE"
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

200 OK
No compression!

If they had been using compression, it would have made all that whitespace fairly negligible.

Probably a result of how their template system stitches everything together. Still, that is pretty bad. There is no excuse to run a webserver and not turn on compression. It is the single biggest way to boost page-load and decrease bandwidth.

* wget 4 lyfe!
** compression is probably evil and Anti-Freedom(tm) somehow, kinda like images are evil or fads like "graphical user interfaces" are evil. In otherwords,anything that makes things easier or faster for a user is basically evil and Anti-Freedom****.
*** braindead comment spamming bots are the only thing not using compression (except RMS, probably)
**** I'll leave it to you, dear reader, to deduce if I'm serious. Hint: no hint.

Sun doesn't want its platform to look even less appealing by allowing ZFS to be built into the Linux kernel. Personally I couldn't care less. I'll just wait for tux3 to mature. It just recently made it into the kernel I should add.

I'm willing to pay for good enough internet services (like Linux Weekly News for example) though, but this is like a punch in the face. Most of the content in last.fm is fucking user contributed!

I also used to pay for Spotify but I cancelled my account when they suddenly decided to drop just about all independent and small-label bands that they didn't have formal on-paper contracts with. 90% of my crust-punk and power-noise/industrial playlists went red because of that, and they still haven't re-added a single band that were dropped. At the same time they also implemented region-based limits.

Back to CDs I guess... or.. err.. what.cd? I dunno...

KVM is part of the default Linux kernel now, and Xen isn't

Um, that's not strictly true. The domU Xen Code is already in the mainline kernel, and there's been some recent discussion to include dom0 as well. Based on a recent LWN article ( Xen: finishing the job ) I'd say there's a very good chance that will happen.

Neat. They benchmarked a bunch of stuff and some real changes obviously took place. I can't help but be comforted by their conclusion (paraphrased): "Stuff changed."

How about telling me why they changed.

• Why did 2.6.29 double it's speed doing SSL signings?
• Why did all the graphics tests speed up some?

• Why did SQLite performance bomb for 3 releases?

• What was the deal with 7-zip performance changing so much? What is it stressing that other tests aren't that cause it to vary?

There are reasons for these things. You could test and find them out. You could read the mailing lists and see if someone else posted explanations (others must have noticed the SQLite thing).

Heck, look at this list of new features and make guesses. I'd prefer "the newly added HyperScheduler v3.732 is probably the source of this" than the article's "things got faster, neat."

That's why I love LWN and the kernel page so much. They post why things changed, or at least reasonable theories.

I am impressed that Torvalds knows about this issue, and credo to him for raising people's awareness.

There's rather more community history behind it than that. The below is from memory based on various coverage I read on LWN and the like, but not fact-checked to be positive my memory is correct, so verify before acting on it as fact.

I believe it was at the annual linux.conf.au, tho I'm not sure but it was some such conference, widely attended by Linux kernel hackers, that the presentation was made. There was apparently a fairly big charity pledge drive related to the issue, with many of the kernel hackers taking part. Various ones of them, in addition to pledging their own money, pledged various acts should the conference pledge drive reach whatever goal ($10K, maybe?).

Well, the pledge drive was quite a success, and the various hackers either have or are in the process of fulfilling their various promises as a result. One of the ones that made Linux hacker community (and LWN) headlines was Bdale Garbee's pledge, to shave his beard. He hadn't been beardless in, I think, well over a decade (15 years? longer?). There was an LWN article on it with a photo (taken I believe at the closing ceremony or traditional post-conference party) of Linus as barber, doing the honors! =:^)

That's actually how I first heard about the whole thing, seeing that photo and reading the accompanying article. But apparently Linus' own pledge was to name a kernel version after the Tazmanian Devil. But he has actually gone one better, changing the logo for .29 as well as the name.

This logo, BTW, is the one the kernel framebuffer driver optionally displays at the top of the screen during boot, if the framebuffer is activated and the config option set to do so. There's a single logo displayed for every CPU/core, so my dual dual-core Opteron displays a nice row of four such logos. I can only imagine the row of 32 of the things on say a quad-socket oct-core machine. =:^)

Anyway, I've been running a kernel compiled directly from git for a few months now (switching to the stable series between release and rc2 or so, only running mainline git between rc2 and release), and am currently running:

$uname -r
2.6.29-rc8-223-ga1e4ee2

So I've had the pleasure of seeing four of these little beasties at boot for a week or so, now. =:^)

Anyway, it's not just Linus. It's the entire kernel hacker community that got involved, thanks to linux.conf.au. =:^)

All that said, while I obviously knew more about the Linux/kernel community side of things and had a bit of general awareness from that, I hadn't bothered reading up on the disease itself until taking the opportunity to click that nice wikipedia link you so thoughtfully provided. Now I know a bit more about it, and am hopefully returning the favor with the above info on the Linux community side of things.

OK, I did an LWN search and here's some relevant links, so folks can fact-check what I wrote above, as well as quote something more authoritative than just some /. post.

LWN 2.6.29 kernel announcement (mentions the code name):
http://lwn.net/Articles/325047/

That points to Linus' actual announcement (LKML announcement as seen on LWN):
http://lwn.net/Articles/325048/

The kernel gets a new logo (a comment links the actual git commit by Rusty Russel):
http://lwn.net/Articles/323966/

Beardless Bdale (It'd be interesting to see the stats for this one as related to the Linus in a swimsuit one, I think also linux.conf.au from a few years ago, dunk tank FWIW, see below.)
http://lwn.net/Articles/316282/

(FWIW, LCA/linux.conf.au, correct. AU$35-40K raised according to "beardless". With the awareness brought by 2.6.29 related publicity, hopefully much more

I am impressed that Torvalds knows about this issue, and credo to him for raising people's awareness.

There's rather more community history behind it than that. The below is from memory based on various coverage I read on LWN and the like, but not fact-checked to be positive my memory is correct, so verify before acting on it as fact.

I believe it was at the annual linux.conf.au, tho I'm not sure but it was some such conference, widely attended by Linux kernel hackers, that the presentation was made. There was apparently a fairly big charity pledge drive related to the issue, with many of the kernel hackers taking part. Various ones of them, in addition to pledging their own money, pledged various acts should the conference pledge drive reach whatever goal ($10K, maybe?).

Well, the pledge drive was quite a success, and the various hackers either have or are in the process of fulfilling their various promises as a result. One of the ones that made Linux hacker community (and LWN) headlines was Bdale Garbee's pledge, to shave his beard. He hadn't been beardless in, I think, well over a decade (15 years? longer?). There was an LWN article on it with a photo (taken I believe at the closing ceremony or traditional post-conference party) of Linus as barber, doing the honors! =:^)

That's actually how I first heard about the whole thing, seeing that photo and reading the accompanying article. But apparently Linus' own pledge was to name a kernel version after the Tazmanian Devil. But he has actually gone one better, changing the logo for .29 as well as the name.

This logo, BTW, is the one the kernel framebuffer driver optionally displays at the top of the screen during boot, if the framebuffer is activated and the config option set to do so. There's a single logo displayed for every CPU/core, so my dual dual-core Opteron displays a nice row of four such logos. I can only imagine the row of 32 of the things on say a quad-socket oct-core machine. =:^)

Anyway, I've been running a kernel compiled directly from git for a few months now (switching to the stable series between release and rc2 or so, only running mainline git between rc2 and release), and am currently running:

$uname -r
2.6.29-rc8-223-ga1e4ee2

So I've had the pleasure of seeing four of these little beasties at boot for a week or so, now. =:^)

Anyway, it's not just Linus. It's the entire kernel hacker community that got involved, thanks to linux.conf.au. =:^)

All that said, while I obviously knew more about the Linux/kernel community side of things and had a bit of general awareness from that, I hadn't bothered reading up on the disease itself until taking the opportunity to click that nice wikipedia link you so thoughtfully provided. Now I know a bit more about it, and am hopefully returning the favor with the above info on the Linux community side of things.

OK, I did an LWN search and here's some relevant links, so folks can fact-check what I wrote above, as well as quote something more authoritative than just some /. post.

LWN 2.6.29 kernel announcement (mentions the code name):
http://lwn.net/Articles/325047/

That points to Linus' actual announcement (LKML announcement as seen on LWN):
http://lwn.net/Articles/325048/

The kernel gets a new logo (a comment links the actual git commit by Rusty Russel):
http://lwn.net/Articles/323966/

Beardless Bdale (It'd be interesting to see the stats for this one as related to the Linus in a swimsuit one, I think also linux.conf.au from a few years ago, dunk tank FWIW, see below.)
http://lwn.net/Articles/316282/

(FWIW, LCA/linux.conf.au, correct. AU$35-40K raised according to "beardless". With the awareness brought by 2.6.29 related publicity, hopefully much more

I am impressed that Torvalds knows about this issue, and credo to him for raising people's awareness.

There's rather more community history behind it than that. The below is from memory based on various coverage I read on LWN and the like, but not fact-checked to be positive my memory is correct, so verify before acting on it as fact.

I believe it was at the annual linux.conf.au, tho I'm not sure but it was some such conference, widely attended by Linux kernel hackers, that the presentation was made. There was apparently a fairly big charity pledge drive related to the issue, with many of the kernel hackers taking part. Various ones of them, in addition to pledging their own money, pledged various acts should the conference pledge drive reach whatever goal ($10K, maybe?).

Well, the pledge drive was quite a success, and the various hackers either have or are in the process of fulfilling their various promises as a result. One of the ones that made Linux hacker community (and LWN) headlines was Bdale Garbee's pledge, to shave his beard. He hadn't been beardless in, I think, well over a decade (15 years? longer?). There was an LWN article on it with a photo (taken I believe at the closing ceremony or traditional post-conference party) of Linus as barber, doing the honors! =:^)

That's actually how I first heard about the whole thing, seeing that photo and reading the accompanying article. But apparently Linus' own pledge was to name a kernel version after the Tazmanian Devil. But he has actually gone one better, changing the logo for .29 as well as the name.

This logo, BTW, is the one the kernel framebuffer driver optionally displays at the top of the screen during boot, if the framebuffer is activated and the config option set to do so. There's a single logo displayed for every CPU/core, so my dual dual-core Opteron displays a nice row of four such logos. I can only imagine the row of 32 of the things on say a quad-socket oct-core machine. =:^)

Anyway, I've been running a kernel compiled directly from git for a few months now (switching to the stable series between release and rc2 or so, only running mainline git between rc2 and release), and am currently running:

$uname -r
2.6.29-rc8-223-ga1e4ee2

So I've had the pleasure of seeing four of these little beasties at boot for a week or so, now. =:^)

Anyway, it's not just Linus. It's the entire kernel hacker community that got involved, thanks to linux.conf.au. =:^)

All that said, while I obviously knew more about the Linux/kernel community side of things and had a bit of general awareness from that, I hadn't bothered reading up on the disease itself until taking the opportunity to click that nice wikipedia link you so thoughtfully provided. Now I know a bit more about it, and am hopefully returning the favor with the above info on the Linux community side of things.

OK, I did an LWN search and here's some relevant links, so folks can fact-check what I wrote above, as well as quote something more authoritative than just some /. post.

LWN 2.6.29 kernel announcement (mentions the code name):
http://lwn.net/Articles/325047/

That points to Linus' actual announcement (LKML announcement as seen on LWN):
http://lwn.net/Articles/325048/

The kernel gets a new logo (a comment links the actual git commit by Rusty Russel):
http://lwn.net/Articles/323966/

Beardless Bdale (It'd be interesting to see the stats for this one as related to the Linus in a swimsuit one, I think also linux.conf.au from a few years ago, dunk tank FWIW, see below.)
http://lwn.net/Articles/316282/

(FWIW, LCA/linux.conf.au, correct. AU$35-40K raised according to "beardless". With the awareness brought by 2.6.29 related publicity, hopefully much more

I am impressed that Torvalds knows about this issue, and credo to him for raising people's awareness.

There's rather more community history behind it than that. The below is from memory based on various coverage I read on LWN and the like, but not fact-checked to be positive my memory is correct, so verify before acting on it as fact.

I believe it was at the annual linux.conf.au, tho I'm not sure but it was some such conference, widely attended by Linux kernel hackers, that the presentation was made. There was apparently a fairly big charity pledge drive related to the issue, with many of the kernel hackers taking part. Various ones of them, in addition to pledging their own money, pledged various acts should the conference pledge drive reach whatever goal ($10K, maybe?).

Well, the pledge drive was quite a success, and the various hackers either have or are in the process of fulfilling their various promises as a result. One of the ones that made Linux hacker community (and LWN) headlines was Bdale Garbee's pledge, to shave his beard. He hadn't been beardless in, I think, well over a decade (15 years? longer?). There was an LWN article on it with a photo (taken I believe at the closing ceremony or traditional post-conference party) of Linus as barber, doing the honors! =:^)

That's actually how I first heard about the whole thing, seeing that photo and reading the accompanying article. But apparently Linus' own pledge was to name a kernel version after the Tazmanian Devil. But he has actually gone one better, changing the logo for .29 as well as the name.

This logo, BTW, is the one the kernel framebuffer driver optionally displays at the top of the screen during boot, if the framebuffer is activated and the config option set to do so. There's a single logo displayed for every CPU/core, so my dual dual-core Opteron displays a nice row of four such logos. I can only imagine the row of 32 of the things on say a quad-socket oct-core machine. =:^)

Anyway, I've been running a kernel compiled directly from git for a few months now (switching to the stable series between release and rc2 or so, only running mainline git between rc2 and release), and am currently running:

$uname -r
2.6.29-rc8-223-ga1e4ee2

So I've had the pleasure of seeing four of these little beasties at boot for a week or so, now. =:^)

Anyway, it's not just Linus. It's the entire kernel hacker community that got involved, thanks to linux.conf.au. =:^)

All that said, while I obviously knew more about the Linux/kernel community side of things and had a bit of general awareness from that, I hadn't bothered reading up on the disease itself until taking the opportunity to click that nice wikipedia link you so thoughtfully provided. Now I know a bit more about it, and am hopefully returning the favor with the above info on the Linux community side of things.

OK, I did an LWN search and here's some relevant links, so folks can fact-check what I wrote above, as well as quote something more authoritative than just some /. post.

LWN 2.6.29 kernel announcement (mentions the code name):
http://lwn.net/Articles/325047/

That points to Linus' actual announcement (LKML announcement as seen on LWN):
http://lwn.net/Articles/325048/

The kernel gets a new logo (a comment links the actual git commit by Rusty Russel):
http://lwn.net/Articles/323966/

Beardless Bdale (It'd be interesting to see the stats for this one as related to the Linus in a swimsuit one, I think also linux.conf.au from a few years ago, dunk tank FWIW, see below.)
http://lwn.net/Articles/316282/

(FWIW, LCA/linux.conf.au, correct. AU$35-40K raised according to "beardless". With the awareness brought by 2.6.29 related publicity, hopefully much more

Duh.

No? Um, how about a contrived wrench-things-back-on-topic suggestion of Tuz For President?

For personal reasons, I do not browse the web from my computer. (I also have not net connection much of the time.) To look at page I
send mail to a demon which runs wget and mails the page back to me. It is very efficient use of my time, but it is slow in real time.

OpenBSD mailing list

The guy is basically a throwback to the "good old days" of computing, and quite frankly, his actions make me think he wishes we'd all go back in time with him.

Your browser is running non-free HTML! What's become of your old self that refused to use browsers? You're such a sellout.

How does Stallman use the web?

Here's how.

I wonder if RMS visits any websites at all besides fsf.org

I'm glad you asked. Let's get a direct quote from the man himself:

"For personal reasons, I do not browse the web from my computer."

At the risk of obvious ridicule he doesn't give the reasons behind this choice, but that's not really important here. Stallman is truly out of touch with the real needs of people who actually use computers on a daily basis. He is out of touch by his own choice. What really burns my taters is that so few properly chastise Stallman for this foolishness. Even worse, some actually defend it.

Short answer: only one thing I mentioned involved disk I/O, RAM is cheap.

Not in modern architectures and it depends. Registers are faster than L1 caches. L1 caches are faster than L2 caches, etc.

See: http://lwn.net/Articles/250967/ for an excellent discussion about how one can dramatically speed up applications by optimizing memory access.

And I disagree with the title of this thread - Linux (the kernel at least) is quite well prepared for multicore chips.

try this:
http://lwn.net/Articles/324196/

These may seem far fetched to you, but they are possibilities that become unpossibilities one you start switching devices to non-ubiquitous filesystem. So, here's the bigger question: why close those doors?

Its best to avoid making assumptions as to what someone else may find far fetched, I in no way disagree with the value of interoperabilty. The only reason linux and TomTom use FAT is for interoperability not because Microsoft has some amazing "IP" and everyone wants FAT. However, you do bring up an important point, the bigger question, why close those doors? Considering the threat to all the hardware manufacturers affected by the interoperability issues you highlight it seems its time to dump the dead weight baggage of Microsoft's FAT patent lunacy and bring an open format to ubiquity.

April 16, 2008 ELC: Trends in embedded Linux

Usage of Linux in embedded development projects crossed a threshold this year, with more than 50% of the 812 respondents saying that they are currently using it. Usage of Linux has been growing year over year, but didn't cross the halfway mark until 2008. More than 61% believed their company would be using Linux within the next two years.

December 04 2003 Microsoft to Charge for FAT File System

January 11, 2006 Microsoft's FAT Patent Upheld

January 13, 2006 FAT Patent Means Hardware Dollars For Microsoft

February 20, 2007 Ballmer repeats threats against Linux

February 25, 2009 Microsoft sues TomTom over Linux and other patent claims

Hardware manufacturers are caught in a catch 22, decouple from the Microsoft monopoly and risk losing market as I assume you are suggesting or remain fully engaged in the Microsoft monopoly and have your margins, market, and product plans somewhat dictated by Microsoft.

As someone who has worked in the brutally competitive hardware industry for many years I can see that its time for hardware manufacturers to show some back bone and beat down the fat and lazy leech that Microsoft has become.

As a bonus, you can easily add web filtering and block things like Slashdot at work.

Actually, browsing Slashdot, The Old New Thing, lwn.net and so on has made me more productive overall. Preventing users from accessing "time wasters" is a losing strategy: not only is the blocking technically futile, but by treating employees like children, you kill morale. Instead of micromanaging their days, treat employees like responsible adults and evaluate them based on their work and its results.

Well most of the Linux eyeballs are not developers either, people have looked at the authors of signoffs on Linux

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

Developers with the most signoffs
Andrew Morton 1422 13.7%
Linus Torvalds 1366 13.2%
David S. Miller 483 4.7%
Jeff Garzik 331 3.2%
Greg Kroah-Hartman 269 2.6%
Al Viro 241 2.3%
Paul Mackerras 232 2.2%
Andi Kleen 177 1.7%
Mauro Carvalho Chehab 170 1.6%
Russell King 166 1.6%
Adrian Bunk 120 1.2%
Arnaldo Carvalho de Melo 119 1.1%
Ralf Baechle 117 1.1%
James Bottomley 109 1.1%
Patrick McHardy 96 0.9%
Jiri Slaby 94 0.9%
Avi Kivity 87 0.8%
Josef Sipek 79 0.8%
Paul Mundt 78 0.8%
Gerrit Renker 78 0.8%

It drops off I'd say exponentially. I'd guess there are much more people working on Windows 7 at Microsoft.

How did the parent comment get "+4 interesting" when it so full of gross errors?

Ubuntu depends on the kernel and GNOME developers funded by Red Hat. Red Hat contributes everything back into the upstream projects, which Ubuntu has been noticeably bad about doing.

RHEL has both GNOME and KDE (and obviously X11).

Rich.

The place to look would be Extramdura in Spain, they have been using Linux for a long time. They claim very, very low costs. I don't have any recent posts but LWN wrote about it in 2003, and last time I heard it was still going strong.

Anyway, besides the necessary <sarcasm> tags, you forgot the informative link:

Cryptographic weakness on Debian systems

I think it was fixed 2 years ago, BTW. But feel free to verify it--you have the source.

He was a great hacker, it's nice to know that more people will remember him.

Will the traditional flash file systems (jffs2) etc. still work when we have SSD's interfacing over SATA? USB sticks don't work with it because they 'pretend' to be a hard drive over USB, and same for the SSD's over SATA. jffs wants the flash device (MTD) interface.

Intel employee Matthew Wilcox spoke at linux.conf.au about some kernel performance improvements related to the Intel SSD drives - redundant ATA calls that have been removed, and allowing larger sector sizes under ATA 8, so maybe the authors of this article should look to a recent Linux kernel.

That's not quite true. Most of the use of a netbook doesn't need a powerful CPU, it's true. Currently my Atom-powered netbook has clocked itself down to 1 Ghz; for posting on slashdot, nothing more is necessary. However, that's not to say that there is never a need for it to scale back up. It's like your car (come on, you knew that was coming): you don't usually drive it as fast as it will go, but it's nice to be able to go fast if you have to.

I would want a faster processor if only to reduce bootup time. Although I hear that others have made do with the existing processor limitations.

Also, eight hours on a charge? Where can I get me some of that?

Seems like the author is not actually aware of how Linux works. Read-ahead has been implemented for a while (there's even a post-boot component similar to Superfetch on Windows).

This is more likely the continuation of http://lwn.net/Articles/299483/, where they improved read-ahead with some kernel-based patches among other things, rearranged the process initialization order, etc.

Also, what's with the wordf**k the author created that I (and I'm pretty sure a lot of other people) had to re-read 5 times before the point s/he was trying to put across was understood. And what's with the trollish injection of politics into a discussion about linux boot times?

http://lwn.net/Articles/299483/

X is still problematic. "We had to do a lot of damage to X," Arjan said. Some of the work involved eliminating the C compiler run by re-using keyboard mappings, but other work was more temporary. The current line of X development, though, puts more of the hardware detection and configuration into the kernel, which should cut the total startup time. Since part of the kernel's time budget is already spent waiting for hardware to initialize, and it can initialize more than one thing at a time, it's a more efficient use of time to have the kernel initialize the video hardware at the same time it does USB and ATA. X developer Keith Packard, in the audience and also an Intel employee, offered help. Setting the video mode in the kernel would not let the kernel initialize it at the same time as the rest of the hardware, as shown in figure 3. The fast-booting system does not use GDM but boots straight to a user session, running the XFCE desktop environment. Instead of GDM, Arjan said later, a distribution could boot to the desktop session of the last user, but start the screensaver right away. If a different user wanted to log in, he or she could use the screensaver's "switch user" button.

C Compiler? WTF?

The EU is a Union, not a country. Many countries have their version of Linux, AFAIK. Portugal has CaixaMágica, Spain has at least 5 (one for each region :P).

http://lwn.net/Distributions/#country

Search on google for: gnash clean room

What you will find is that Adobe made it difficult to legally work on an open source viewer, and that the specs that exist are either (1) leaked, and therefore it is questionable whether you can legally use them, or (2) from a clean room reverse engineering.

From: http://lwn.net/Articles/270056/

Gnash development has been done using a Clean room reverse engineering technique. By agreeing to the license for the Adobe (formerly Shockwave) Flash player, a developer gives up the right to develop a competing product.

From: http://www.gnashdev.org/?q=node/30

Rob: The Adobe EULA for Flash forbids anyone who has installed their Flash tools or plugin from working on Flash technologies. This has had a chilling effect on the development of free Flash players, since a developer must either choose to decide that Adobe won't sue them over this, or to do what Gnash does, which is a slow and inefficient, clean room, reverse engineering project.

Adobe has declined to comment on this issue, since the confusion benefits their lockin of the market. Although Adobe has said they support Open Source projects, and donated Tamarin to Mozilla, we'd love to see a public statement that Gnash developers won't be subject to a lawsuit. It's very difficult to find developers that have never installed the Adobe software ever, which is what we've been doing to maintain our clean room approach.

From: http://www.openmedianow.org/?q=node/21

Savoye suggests that, "Most of this documentation, if we really wanted it, has already leaked out on the Internet years ago."

If he did, how would he be able to surf the internet using his email?

And besides, who wants to watch video or listen to music when you can be using Emacs and Free(tm) software? Freedom(tm) trumps everything for him, to a huge fault. "Freedom" trumps usability, marketability, developer freedom, you name it.

That is why most ignore him.

The problem with (originally) Android-based devices is that their power management is done in a completely non-standard way. It's not that it would not be open, but passing tokenized dead mice through a wormhole is quite a pain. Will there be enough community interest to actually ever put the power management to a level that can be used by non-Android distributions?

This is where the Neo FreeRunner shines - not only you can install Debian (or Gentoo) on the device, but you can actually use it as your daily phone / GPS device / music player to a similar extent you can use the Openmoko distribution.

It's not just, or it should not just be a "fun hack" to install Debian on your phone - the point should be that you can use your phone with Debian, similar to what you done on your desktop/laptop computer. Of course, there should not be any need to hack the phone before being able to install own programs on it, but there is already the Android dev phone available so that's not the problem with Google phones.

It's possible. And it has already been done with Linux: http://lwn.net/Articles/299483/

Now it'll just require some time to trickle down to production-quality distros.

And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).

Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.

Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.

I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).

The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.

udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.

FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...

There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.

cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).

Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).

There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.

Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)

And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).

Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.

Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.

I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).

The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.

udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.

FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...

There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.

cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).

Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).

There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.

Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)

And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).

Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.

Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.

I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).

The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.

udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.

FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...

There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.

cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).

Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).

There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.

Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)

Wouldn't setting security.ssl3.rsa_rc4_128_md5 to false prohibit these kind of attacks?

After reading about it on lwn.net, I learned that this setting does not protect you against this particular problem (but setting it to false doesn't hurt). I also learned that the certificate for lwn.net is signed using md5, so if the setting worked you would get a warning or error when trying to access lwn.net with https. If you want to try it out yourself here are two sites with md5 based certificates lwn.net and ssl247.com. It's just the leaves that are signed using md5, if the attack was used it would moste likely be an intermediate CA that was signed using md5. I tested this in both firefox and seamonkey, neither gave any warning.

Wouldn't setting security.ssl3.rsa_rc4_128_md5 to false prohibit these kind of attacks?

After reading about it on lwn.net, I learned that this setting does not protect you against this particular problem (but setting it to false doesn't hurt). I also learned that the certificate for lwn.net is signed using md5, so if the setting worked you would get a warning or error when trying to access lwn.net with https. If you want to try it out yourself here are two sites with md5 based certificates lwn.net and ssl247.com. It's just the leaves that are signed using md5, if the attack was used it would moste likely be an intermediate CA that was signed using md5. I tested this in both firefox and seamonkey, neither gave any warning.

Not going to happen. This is a man who, by his own admission, doesn't surf the web.

I think RMS is probably continually amused by how seriously people take him when he goes off about things like that, based on how he acted when he gave a speech at a nearby university. But it doesn't really come across online and he just looks like a nut...

It may be useful for you to read LWN's embedded nightmare prologue along with the original Embedded Nightmare article. If you have written extra drivers and can get them into the mainline kernel them the benefits of going with a new 2.6 could be big...