Slashdot Mirror

The only solution is to regularly read everything:

The chance of avoiding double errors in the form of unreadable sectors during rebuild about doubles each time you halve the time between full reads of all sectors on a drive. (True to about weekly full reads.)

This is because a full read will allow each drive in the array to discover sectors that are becoming iffy (soft/recoverable read errors) and then remap them.

See lwn.net for a discussion and links to some good papers.

Terje

These are only a few of the changes in disk hardware that will occur over the next decade. What do these changes mean for file systems? First, fsck will take a lot longer in absolute terms, because disk capacity is larger, but disk bandwidth is relatively smaller, and seek time is relatively much larger. Fsck on multi-terabyte file systems today can easily take 2 days, and in the future it will take even longer! Second, the increasing number of I/O errors means that fsck is going to happen a lot more often - and journaling won't help. Existing file systems simply weren't designed with this kind of I/O error frequency in mind.

These problems aren't theoretical - they are already affecting systems that you care about. Recently, the main server for Linux kernel source, kernel.org, suffered file system corruption from a failure at the RAID level. It took over a week for fsck to repair the (ext3) file system, when it would have taken far less time to restore from backup.

article from 2006: http://lwn.net/Articles/190222/

You might want to read this article. The illusion that running Linux makes you safe and that Linux machines aren't involved in spam-sending botnets is just that: an illusion.

As for firewalls protecting insecure systems: they do, to an extent. But the firewall isn't going to stop you from getting infected by, say, visiting a website with malicious code on it, opening an email attachment with such, or installing and running software with malicious code in it.

It's not so much Windows instant-on that people care about, it's something better than the same-day service currently offered by Vista after you hit the power switch. If you could tune the OS to boot in 10-20s (or even 5s like the Linux Plumbers did recently this wouldn't even be something you'd need to ask users about.

This bug could've been a showstopper. It essentially ruined your intel e1000e ethernet card, by overwriting the firmware. They've not patched it, according to LWN:

It is worth noting that, as of this writing, 2.6.27 does not contain a fix for the e1000e hardware corruption bug. What it does contain, though, is a series of patches which will prevent that bug from actually damaging the hardware. That makes the kernel safer to run, which is an important step in the right direction.

What does that mean? Obviously, it should not ruin your ethernet card anymore, but will e1000e work very well with this kernel? Or what?

Since this is a pretty high-profile bug it's strange it ain't mentioned in the summary. E1000e is a very popular gigabit ethernet chip from Intel, and actual hardware corruption is serious and (luckily) rare.

I've administrated network authenticated openSUSE machines and they definitely benefited from booting faster (compared to older versions of openSUSE) - after all the sooner the kernel finishes the sooner you can start waiting for that DHCP lease...The key is that the moment someone says they want to run NIS/LDAP/NFS you just say "start everything that doesn't depend on the network while you wait for the network to come up". In your case NIS/NFS/autofs/xdm DO need the network so they have to wait until that DHCP lease is acquired. No functionality need be lost but the dependencies/order of certain events need to be maintained (this is what tools like Upstart are about).

Strangely enough in one of the article's comments you'll find that Arjan isn't advocating a parallel boot:

Parallel boot is the wrong thing; it ends up meaning that you're not really doing the critical path in sequential order; but let the system get distracted from that.

Asynchronous boot (where you let the critical path go sequential, and non-critical pieces asynchronous) is the right answer; the article has a graph about this. And Asynchronous boot you can do just fine with SysVinit.... no magic about that.

Ultimately I doubt people are advocating all of this work for your typical network workstation. For starters such systems don't tend to be using solid state disks with unattended login...

No it isn't, since simply no OSS application matches the features Skype provides accross platforms.

I wasn't saying that such software exists at the moment. I was just making the more general point that an open-source application with Skype's functionality would be less likely to secretly harbor such snooping and filtering functionality.

Then they should start paying developers to make it possible to communicate with other people.

They're trying. Can they count on your donation?

I read in an interview a while ago that he uses Debian Linux on his laptop and since this is a distro that installs a GUI by default, he might well use Firefox. Even on a command-line only machine, he could use Lynx as a browser.

Sure, he's written a heap of command-line only tools but I don't ever recall him saying anywhere that he doesn't use a GUI or a browser.

Apparently, you've missed Stallman's now-infamous post on the subject:

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.

Here's a poweropint presentation about this work. If you're an LWN subscriber you can you read an article and comments about the 5 second boot presentation at the Linux Plumbers Conference (it will become viewable by all on from the 2nd October 2008). Finally you might be able to test drive some of this work if you are willing to sacrifice a USB key and destroy your existing EeePC install by because Moblin may include this work.

http://lwn.net/Articles/272048/

I'm pretty sure he's referring to this. It was a Linux kernel vulnerability that GCC exposed, not a bug in GCC.

Of course, that alone is hardly enough to warrant his first two statements: "With all the GCC bugs Linux has? With the poor track record on security?"

If he has something else in mind, he'll have to bring it up himself.

RMS, ahead of the game once again

http://lwn.net/Articles/262570/

At the just-concluded Linux Plumbers Conference, Arjan van de Ven and Auke Kok demonstrated a netbook that went from powered off to GUI up in five seconds. Jaws dropped around the room. I haven't seen a formal write-up yet -- maybe LWN will cover it? -- but you can get a taste from the conference notes.

High points that I remember:

• Eliminate silly time-wasters. Starting X involved running the compiler (!) to preprocess a config file.
• Determine which files are needed to boot, then start the boot by kicking off a super read-ahead program to suck those files into the page cache.
• Boot to a stripped-down GUI, not to full-up Gnome.
• Let networking come up asynchronously.

For some reason Fedora has to re-key all their repos and, while I think that's done, it's still being mirrored. One would assume a signing key has been lost.

Have you already read the Fedora report? Fedora did release a report about the incident. Within it they say that while an attacker was able to reach a Fedora signing system they do not believe that the key's passphrase was compromised. However it states that as precaution they have decided to create a new key.

The Red Hat side of things is different and far... trickier. I point you towards this LWN article about the intrusion as I think it's hard to say such simple statements about it.

For some reason Fedora has to re-key all their repos and, while I think that's done, it's still being mirrored. One would assume a signing key has been lost.

Have you already read the Fedora report? Fedora did release a report about the incident. Within it they say that while an attacker was able to reach a Fedora signing system they do not believe that the key's passphrase was compromised. However it states that as precaution they have decided to create a new key.

The Red Hat side of things is different and far... trickier. I point you towards this LWN article about the intrusion as I think it's hard to say such simple statements about it.

Note also, this interview with Welte on the same topic:

http://lwn.net/Articles/291636/

Firefox 3.1 is going to add Theora video and Vorbis music support for video and music HTML5 tags. The picture quality will probably be better than FLV (but worse than H264 in the short term, although work is being done to improve this.

Flash does dramatically more than video mind...

1) Get linked on Slashdot
2) Have servers turned into smoldering remains
3) Take servers offline
4) Turn on caching
5) Put servers online again
6) ???
7) Proffit

(Sorry, I just couldn't resist...)

Here's a post addressing this on lwn:
http://lwn.net/Articles/272973/

Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.

Debian focused on and solved this problem with their FHS (the whole lwn discussion on LSB4 is here), and take packaging and interoperability seriously (they also take distribution seriously, but other distros do that too). But IMHO, Debian represents the amount of rigor, effort, and time it takes to get these non-glamorous 'administrative' things right. In particular, a commitment to 'must pass defined installation/filesystem/interoperability test suite' over 'rpm -i seems to drop stuff in place ok' is historically sufficient to make installation reliable, and you could moot the point as to whether it's necessary now, and importantly, in the future.

If developers provided hints (in the form of a skeleton debian control or rpm spec file) describing even roughly

• how their .tar.gz divides into logical installable parts
• what dependencies they know it needs to build and run
• generally what dirs in the .tar.gz contain libs, executables, docs, and config files

I think it would go a long way towards helping distribution authors. Even a text file (README.packagers.txt) with a couple paragraphs of prose describing this would give a big boost to packagers, and in turn, to the interoperability of the software with others as a good distro constituent. Debian recognized this, and IMHO the sooner developers visualize helping distribution creators by feeding this kind of information forward, the sooner distributions will converge on internal interoperability, leading to higher quality distributions, and subsequently to FLOSS maturing faster.

Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.

Debian focused on and solved this problem with their FHS (the whole lwn discussion on LSB4 is here), and take packaging and interoperability seriously (they also take distribution seriously, but other distros do that too). But IMHO, Debian represents the amount of rigor, effort, and time it takes to get these non-glamorous 'administrative' things right. In particular, a commitment to 'must pass defined installation/filesystem/interoperability test suite' over 'rpm -i seems to drop stuff in place ok' is historically sufficient to make installation reliable, and you could moot the point as to whether it's necessary now, and importantly, in the future.

If developers provided hints (in the form of a skeleton debian control or rpm spec file) describing even roughly

• how their .tar.gz divides into logical installable parts
• what dependencies they know it needs to build and run
• generally what dirs in the .tar.gz contain libs, executables, docs, and config files

I think it would go a long way towards helping distribution authors. Even a text file (README.packagers.txt) with a couple paragraphs of prose describing this would give a big boost to packagers, and in turn, to the interoperability of the software with others as a good distro constituent. Debian recognized this, and IMHO the sooner developers visualize helping distribution creators by feeding this kind of information forward, the sooner distributions will converge on internal interoperability, leading to higher quality distributions, and subsequently to FLOSS maturing faster.

Atheros hired Luis R. Rodriguez, the developer of the Linux kernel Atheros driver, back in April with the intention of doing just this. Congratulations!

I posted this also at Secrecy and the DNS flaw :

The solution is apparently to start used random selected UDP source ports on the nameserver when answering to DNS requests. Well the new problem has with this solution already been created : "Vulnerability in IANA root servers, servers go down after UDP port storm."

The only sensible solution is to create a hierarchical slaves.conf access list. WHO are allowed recursive access to higher up bind servers? Besides selection using ip-numbers, one can also be awarded with a valid DNS SEC hmac-md5 key. Ok I know this is Big Brother style stuff. But i don't know of any DNS hackers who like to leave their identity inside nameserver logs.

The core problem is recursive access to upstream authoratitive DNS servers. ISC should fix this inside bind9. But using random UDP ports opens up a whole new range of even more nasty DoS problems.

a caching DNS server which gets its cache polluted. If the attack setup is such that faulty DNS info is cached, is then the caching DNS server in error? I don't think so. What is needed is authentication and pgp/checksum info to see if the offered DNS info to be cached is valid.

Robert

Or Linux. I don't know if Slackware still has SlackZIP, but it's specifically intended to boot from MSDOS/Windows 9 environments -- which means that you can set it up to run as desired while still having a functioning OS, then replace the bootloader to boot directly to Linux.

I think you mean loadlin, which is one of the boot loaders that linux can use. You boot into DOS and then run loadlin.exe to boot linux.

Or there was a method of installing Slackware into a FAT* filesystem using a UMSDOS kernel I think it was. This is the method that the supposed Tuxissa Virus used to download Slackware and install itself in the background before wiping out Windows. In fact here's another posting about the Tuxissa Virus that details its use of the UMSDOS filesystem.

> Major and minor numbers have their place, too.
> They tell me something about the amount of
> change. I'll update from 2.6.25 to 2.6.26 without
> a second thought, as I expect nothing important
> to have changed.

This is seriously wrong since 2004. Nowadays everything released are 2.6.x. A larger x means a later release, and that's it. There is no implication about the amount of changes. And indeed, the amount of code changes happening to Linux these days are so huge that it makes no sense to say 2.6.25 to 2.6.26 must be safe because they are "close" (they are safe for user applications, but even 2.6.5 to 2.6.26 is safe, since very few changes of kernel affect userland at all. But if you have a kernel module to compile that's completely unsafe even for 2.6.25 to 2.6.26). They are not close, every x increment means around 15% of the whole code base has been changed, of which many are very radical changes to code and data structures.

Linus... has... jumped the shark. The number versions... his version control insanities... He's no longer Linux's greatest advantage. He's now doing more to hold back the community than anything else. (dear god this is going to hurt the karma)

Rename article title as "Linus on Crack". You are right, Linus is now only Linux's second greatest advantage, Andrew Morton is the greatest. Linus has always been erratic but great. Lately, he really stepped in it a lot, but he is still maybe the best bug hunter that ever lived. Mind you, he tends to have a large hand in creating the horrible complexities that lead to the need for the bug hunt in the first place, but then if he did not we would never have the pleasure of watching him exercise his art.

      http://lwn.net/Articles/215868/

And yes, I agree, Linus is on crack about the version numbers. Just drop the 2. at the beginning and it will all be fixed.

But he wasn't talking about the GPL was he? He was talking about software licences wasn't he.

"A contract, on the other hand, is an exchange of obligations, either of promises for promises or of promises of future performance for present performance or payment. The idea that 'licenses' to use patents or copyrights must be contracts is an artifact of twentieth-century practice, in which licensors offered an exchange of promises with users: 'We will give you a copy of our copyrighted work,' in essence, 'if you pay us and promise to enter into certain obligations concerning the work.' With respect to software, those obligations by users include promises not to decompile or reverse-engineer the software, and not to transfer the software."

http://lwn.net/Articles/61292/

Dammit, people. The GPL is a license, not a contract. It doesn't need explicit consent from its users. It doesn't need a clickthrough. So why does this software have a clickthrough GPL? This looks to me like a very basic misunderstanding of what the GPL does. I also have some reservations about them making this software GPLv2 only, but that's a very minor thing.

Here's an old but fun method of configuring your kernel:

The Kernel Adventure Configurator

Reading on it, it seems that Linus never has been a great fan of kernel debuggers. From a famous post,

I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. [...]

I agree that stepping with a debugger instead of thinking real hard about the code (and using abundant log statements) is generally a waste of time, and that expecting to catch rare occurrences of weird race conditions with a debugger is not worth the effort. Sloppy programmers don't take the time to think, and rely too much on fixing what they could have not broken. Unit tests, although more expensive to code, can be reused many times - debugging sessions are one-shot.

On the other hand, even good programmers can get stuck and benefit from a debugger every once and then. I guess this argument finally won the day.

It's basically just like SRS (which you need to use if you use SPF) except using it on your own outgoing mail instead of forwarded mail. And by using it, SPF becomes utterly worthless.

The idea is that you use a unique MAIL FROM: for all legit mail you sent, and simply reject all bounce messages that isn't going to these addresses.

See here and here: here for more details.

Seems to me that he is allowed to be an asshole occassionally as long as he can share this kind of information.

Although Red Hat has made contributions to Linux, the OS was fundamentally done by the time Red Hat became invovled. There may be room for one company to be successful holding the corporate hand as they venture into Linux, but as corporations become more comfortable with Linux they may begin to question if Red Hat is adding any value they should be paying for.

What a load of drivel you do write. Red Hat are profitable and have expanded every quarter for at least the past 4 years, and we're selling RHEL licenses in spades, many to huge companies that have advanced in-house Unix/Linux teams. The operating system was not "fundamentally done" when Red Hat came around. Otherwise we'd just still be shipping RHL 1 to everybody. In fact we consistently top the list of kernel contributions, that kernel scaling up and down in ways that no one could even foresee 15 years ago when RH was founded. So stop trolling nonsense and pay attention.

Rich.

Understanding the Linux Kernel has a very good description of most of what you want to know. It, and Linux Device Drivers, certainly helped me get acquainted with the inner parts of the kernel.

Take a look at the Linux driver project or something like GregKH's driver tutorial. You aren't alone in wanting to write drivers for Linux. The catch is that most (new) hardware with specs actually already has drivers available on Linux.

The trick is to start with simple hardware and then work your way up (graphics card drivers ARE hard especially if they have to be reverse engineered). There are also books like the fantastic Linux Device Drivers that describe how drivers can be written.

(Writing drivers is not impossible but it does take time to become good and without specs it's is a tricky trial and error process. If you're even a bit interested, dive in!)

Take a look at the Linux driver project or something like GregKH's driver tutorial. You aren't alone in wanting to write drivers for Linux. The catch is that most (new) hardware with specs actually already has drivers available on Linux.

The trick is to start with simple hardware and then work your way up (graphics card drivers ARE hard especially if they have to be reverse engineered). There are also books like the fantastic Linux Device Drivers that describe how drivers can be written.

(Writing drivers is not impossible but it does take time to become good and without specs it's is a tricky trial and error process. If you're even a bit interested, dive in!)

Linux Weekly News has a comment from an HP developer indicating they aren't putting this out there so it can become a linux file system, but so that the lessons learned and parts of the code that are useful can be incorporated into one of the linux file systems of the future. I took it to mean, take our code and use whatever you can to make ext4 or ext5.
 
 

While it would be fine with HP if someone wants to "port" AdvFS to Linux or any other
operating system with a GPLv2 compatible license, this contribution is not intended to
"compete" with other existing file system projects underway in and around the kernel.org
development community.

Rather, our hope is that the algorithms, design documentation, and test suite now available at
the AdvFS site... and the active participation of HP engineers in various open-source file
system projects who have lots of AdvFS experience... will help to accelerate the inclusion of
AdvFS-like enterprise features and capabilities in next-generation file systems for Linux.

News feeds:

IE Blog - for keeping track of what MS is up to on the browser front
http://blogs.msdn.com/ie/atom.xml

Standards Blog - not as many posts now days, was very important during the height of the ooxml/odf war
http://www.consortiuminfo.org/standardsblog/backend/geeklog.rss

I keep OSNews for completeness, but it is pretty useless - software news
http://osnews.com/files/recent.xml

Anandtech - hardware news and reviews
http://www.anandtech.com/rss/articlefeed.aspx

Ars Technica - tech news and commentary
http://arstechnica.com/index.rssx

Phoronix - linux graphics news and info
http://www.phoronix.com/rss.php

Linux Weekly News
http://lwn.net/headlines/rss

KDE announcements
http://www.kde.org/dotkdeorg.rdf

Open Source Software Planets:

http://planet.debian.org/rss20.xml

http://planet.fedoraproject.org/atom.xml

http://planet.ubuntu.com/rss20.xml

http://planet.gnome.org/atom.xml

http://planetkde.org/rss20.xml

http://planet.freedesktop.org/rss20.xml

http://planet.mozilla.org/atom.xml

http://planet.jabber.org/atom.xml

mostly software releases and XEP updates
http://planet.jabber.org/news/atom.xml

http://maemo.org/news/planet-maemo/atom.xml

environment feeds:

Good Pacific Northwest environmental news
http://www.sightline.org/daily_score/rss

Best environmental news and discussion on the web
http://www.worldchanging.com/index.xml

I keep Treehugger for completeness, but I mark 90% of their posts as read without looking at them.
Really too "light green/consumer green" for me
http://www.treehugger.com/index.xml

other feeds:

Dive into Mark - not what once was, but good enough to keep around
http://diveintomark.org/feed/

Loooong posts on software
http://steve-yegge.blogspot.com/atom.xml

Bruce Scheier knows Alice and Bob's shared secret
http://www.schneier.com/blog/index.rdf

The intersection of Science (especially Evolution), Liberalism, Atheism, and Squid
http://scienceblogs.com/pharyngula/index.xml

"Your comment has too few characters per line" - what a load of bull. Taco, I know this and the timer are supposed to cut down on spam, but I think they annoy legitimate posters more than they reduce spam. You should really reconsider these "features".

The beta is from openSUSE (the non-oss version) ( http://lwn.net/Articles/283566/ )
The actual follow-on one is from the non-oss version of openSUSE ( http://ftp.nluug.nl/os/Linux/distr/opensuse/distribution/11.0/repo/non-oss/EULA.txt )
The one referenced is for the oss version for openSUSE ( http://ftp.nluug.nl/os/Linux/distr/opensuse/distribution/11.0/repo/oss/EULA.txt )

I will leave it as an exercise for the read to determine if it is actually an evil conspiracy or not.

Barriers and journaling filesystems

KVM is nice and shows promise, but performance wise the paravirtualized approach of xen is still significantly faster (as in very-near-bare-metal, even significantly faster than vmware ESX on most loads).

VirtIO, which is in latest versions of KVM, paravirtualizes all the hardware and gives you almost all the benefit.

KVM is where things are going because as a poster said above, it avoids having to write all the drivers twice over. Xen dropped the ball by not working closely with the Linux kernel developers. Now XenSource have been bought out by a Microsoft proxy, so the future for Linux & Xen is looking even less rosy.

As you say, Red Hat offers libvirt which hides the differences between virtualization systems, so for most administrators and application programmers, which system "wins" is not going to matter. (My personal opinion is that none of them will win outright, at least not for many many years - different approaches to virtualization are suitable for different areas).

Rich.

Biometrics are powerful and useful, but they are not keys. They are useful in situations where there is a trusted path from the reader to the verifier; in those cases all you need is a unique identifier. They are not useful when you need the characteristics of a key: secrecy, randomness, the ability to update or destroy. Biometrics are unique identifiers, but they are not secrets. - Bruce Schneier

Um... Actually it is:

http://www.mono-project.com/Moonlight

Microsoft is assisting in Moonlight's development:

http://lwn.net/Articles/248198/

File integrity checking is built into the basic lookup mechanism, so that corruption will be detected automatically

One should, perhaps, wonder what currently unreasonable problem should actually start being addressed RIGHT NOW!!

A while ago I read this article: LWN article about ext4 fs

and your comment reminded me of it. I think it's very impressive that some people can think far ahead.

Matthew Wilcox replaced the per platform semaphore code with a generic implementation because it was likely to be less buggy, reduced code size and most places that are performance critical should be using mutexes now.

Unfortunately this caused a 40% regression in the AIM7 benchmark. The BKL was now a (slower) semaphore and the high lock contention on it was made worse by its ability to be preempted. As the ability to build a kernel without BKL preemption had been removed Linus decided that the BKL preemption would go. Ingo suggested semaphore gymnastics to try and recover performance but Linus didn't like this idea.

As the the BKL is no longer be preemptible it is now a big source of latency (since it could no longer be interrupted). People still want low latencies (that's why they made the BKL preemptible in the first place) so they took the only option left and started work to get rid of the BKL.

(Bah half a dozen other people have replied in the time it's taken me to edit and redit this. Oh well...)

here (for subscribers. I dare not post a free link here :)

Lemme give you an anecdote: fifteen years ago, I received a proprietary program that I used in a research project. It was written for a slightly different architecture, but because I found out that I only had to MODIFY a few low-level C I/O routines in the SOURCE, we could use it on our SGI Indy & spent about a CPU-year using that program to do our calculations. Great success!

The point is, that having access to the source, but not explicitly the right to modify it to suit whatever workstation you have available for your work, is often useless, both in an open source context or in an (effectively) closed-source context.

So, if I understand correctly, if this particular program had been licensed under the Ms-RL license I would have had the same freedom (and then some, because it's apparently an open source license), but if it had been licensed under the Ms-LRL license, it would have been absolutely useless to me, because I wouldn't have access to the same computing platform as where the code had been written, and I would have been forbidden to modify it.

Ms-RL good, Ms-LRL *BAD*. I find this choice of license names by Microsoft very confusing. Especially if you contrast it with the GNU GPL and GNU LGPL (LGPL Less restricted than GPL).

Also, the FSF claims that these Microsoft licenses are incompatible with the GPL (which was written much earlier), so I think Microsoft did this on purpose.

If you're interested, there was a discussion on this on the LWN site last year.

As to the rest of your post, I don't actually understand what you mean, sorry.

I'm fairly sure linking isn't allowed. Please see the other response tree to my post.

It's not whether you distribute the things together, it's whether you distribute your stuff at all.

The GPL explicitly provides that it cannot be used that way. The LGPL is the one for libraries that allow non-GPL stuff to be linked to them. There is a brief discussion of the way ATI/nVidia do things here:

http://lwn.net/Articles/184996/

Which seems to imply they don't link to the kernel with their non-GPL code.

Please explain these Fair Dealing and Fair Use concepts further. I'm interested in how they override the GPL, I don't think they do.