Slashdot Mirror

Maybe this article will shed some light: http://kerneltrap.org/Linux/Comparing_HAMMER_And_Tux3

I find it curious that nobody mentions keywords.

The reason why I did not switch to GIT when Linus created it is that it was not possible to add auto-modifying keywords. With keywords, the SCM can physically modify your files, in precisely marked spots, to indicate the version level of a file in the actual code. I really like this aspect.

At the first publication of GIT, I remember Linus holding a strong stance against keywords. This is why I did not convert to GIT (I am a one-man-company and I do not need to collaborate on code: I need SCM to keep all old versions and changes).

(You can read Linus' stand on this, for example, in this e-mail from 2006)

In the current GIT faq they mention that keyword substitution is "not recommended", but they then point to the man page of gitattributes, which, disappointingly, does not mention keywords.

This is why I keep using SVN. I need my sources to hold within themselves an easily trackable age indication.

GIT problems -

- IDE Integration/Tools
- Traceability/Unified access control

A distributed vcs can do *everything* a centralized one like svn does, but does it better, does more.
Wholly inaccurate. Being able to do more does not mean it can do it better. There are many different needs for a VCS and GIT does not serve them all. Independence isn't a PROBLEM for most development groups. Some organizations aren't at all conducive to this style of "freedom" which isn't helpful to commercial or government organizations (works great for OS I guess) which sacrifice all kinds of efficiency for the ability to backtrace actions.

You get the expected problems with "automatic" merges from untraceable sources.

http://kerneltrap.org/Linux/Tracking_Down_Merge_Errors_With_git

Fortunately, these issues should be fixable if the right people care enough.

Unless DVCS were to store every keystroke related to project files, there's a small difference between wanting to push to a local or central repo (outside of network issues and creating the brach on the central repo). You're functionally notifying different machines. All in all there's not a compelling reason to move to a DVCS unless you need it and I see very few cases where that's true. Even Linus mentions he acts as the kernel central repo although he espouses the fact that it doesn't need to be.

It's human nature to seek and understand organizations as hierarchichal and there's not much chance of anyone changing that for a long time. I'll stick with what other developers implicitly understand.

Uh oh, are you running Linux? Are you aware of the head parking problem with these drives?
http://kerneltrap.org/node/14912

So, something like HAMMER, then?

A HAMMER filesystem can be mounted with an as-of date to access a snapshot of the system. Snapshots do not have to be explicitly taken but are instead based on the retention policy you specify for any given HAMMER filesystem. It is also possible to access individual files or directories (and their contents) using an as-of extension on the file name.

Released and stable in DragonFlyBSD 2.0, and obviously BSD licensed.

people who really like reiser4 might want to take a look at btrfs; it has a number of the same design ideas that reiser3/4 had --- except (a) the filesystem format has support for some advanced features that are designed to leapfrog ZFS, (b) the maintainer is not a crazy man and works well with other LKML developers (free hint: if your code needs to be reviewed to get in, and reviewers are scarce; don't insult and abuse the volunteer reviewers as Hans did --- Not a good plan!).

Here's the thing - unless your main nonvolatile media is as fast and smaller than your RAM swap is still useful. What can happen is that pieces of RAM that are very rarely used (e.g. a program that starts up does something then goes to sleep indefinitely) gets swapped out (which initially seems bad because you're going to pay a large price if you ever have to swap it back in). However that RAM is now free for other uses like caching your disk. So disk access to data you've already read which may involve seeking on rotating media and a lot of waiting now become as fast as your RAM. If you have no swap this tradeoff can never be made and the RAM is effectively never reused.

Looking around this Kenreltrap article contains a thread where someone asks is swap necessary? which might provide a better explanation than the one I've given.

Yeah, things change from day to day and year to year. AM's post says that the swapfile bypasses the OS. But... ...Keep in mind that creating a swapfile uses dd. When dd creates a file there's nothing to specify that the file is contiguous. Therefore it's likely to be fragmented. Whether the fragmentation is significant is another story worthy of benchmarks. Andrew Morton knows this of course, and says to create the swapfile early. I.e., not early in boot time, but soon after the system is installed. Even so, that won't guarantee a contiguous swapfile. May not matter except on a heavily loaded system. But at that point you want it to be as efficient as possible. :P

BTW, there's another developer who mentioned way back that swap partitions were more efficient:

http://kerneltrap.org/mailarchive/linux-activists/1992/10/24/14522

Things have changed of course, and shame on me for breaking my own rule about rules of thumb.... As I said, there's probably not a lot of difference and swapfiles are generally easier to use.

So, imagine you are using a machine with 1 GB of RAM and 2 GB of swap, following the old rule. That adds up to 3 GB of virtual memory. Now you buy your new machine, that has 4 GB of RAM. If you run it totally swapless (which is perfectly possible), and your use of it is more or less the same that the use you gave to your old machine, then why whould you even consider using swap? It's totally pointless to use the "double your RAM" method. If you don't want to go swapless, just put something like 1 GB and it should be enough. You can always add more if you need later. Reference link: http://kerneltrap.org/node/3202

Was the author of this ever found? Two lines of cleverly obfuscated code. http://kerneltrap.org/node/1584

link for the lazy, and a description of the FS.

link for the lazy, and a description of the FS.

This filesystem is meant for embedded devices with Flash storage that presents itself as a portion of physical memory - essentially, it helps the kernel avoid the overhead of copying from Flash to RAM when you can just run it out of Flash.
XiP has been supported in other filesystems, this is more like a small improvement - nothing to get excited about. Moreover, you won't see it in use in any desktops - this filesystem is read-only; more like an archive format understood by the kernel.
More useful discussion can be found at kerneltrap.

http://kerneltrap.org/mailarchive/linux-activists/1991/12/8/420

It's not quite as straightforward as that, but there's a valid objection there, and I take the point.

Of course, the real problem is the idea that users manually editing a 32MB file on a regular basis is at all a sensible idea.

First off, I'd suggest printing out a copy of the GNU coding standards, and not read it. Burn them, it's a great symbolic gesture.

We went through this discussion a couple of weeks ago, and I had absolutely zero interest in explaining it again.

I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. But that also means that there is never a time when you can "let people know", except when it's not an issue any more, at which point there is no _point_ in letting people know any more.

So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special.

So there is no "policy". Nor is it likely to change.

It's a flamebait email thread. Linus has harsh words for BSD. Nobody ever said Linus doesn't do that -- but this is not security through obscurity.

His take on security issues is simply: they're bugs. Deal with it.

We went through this discussion a couple of weeks ago, and I had absolutely zero interest in explaining it again.

I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. But that also means that there is never a time when you can "let people know", except when it's not an issue any more, at which point there is no _point_ in letting people know any more.

So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special.

So there is no "policy". Nor is it likely to change.

It's a flamebait email thread. Linus has harsh words for BSD. Nobody ever said Linus doesn't do that -- but this is not security through obscurity.

His take on security issues is simply: they're bugs. Deal with it.

Hi Brad, Your comments are kind of misguided. Linus can be quoted as saying: "my responsibility is to do a good job. And not pander to the people who want to turn security into a media circus." He was referring to individuals such as yourself when making the circus comment, as your message was slightly alarmist and dramatized. Security is important, of course - but Linus' opinions are completely correct in terms of development of the Linux kernel. I would agree with you if security bugs were actually being hidden, but they aren't. They just aren't given special treatment.

From here

See the Kerneltrap posting which includes a good part of the email discussion.

It looks like Linus' main concern is that publicizing a few bugs as "security" issues will act to hide other real security issues that weren't recognized at fix time; that any effort to publicize security issues will be so incomplete as to be misleading. And I see no mention of these concerns in the linked postings, almost as if the "full disclosure" people posting them are afraid to disclose the potential bugs (which would automatically be security bugs because of the topic) in their own methodologies.

It's GPL'ed, it doesn't need to be, nor should it be put in the public domain.

As a matter of fact though, someone recently got it to build with a modern toolchain so that it can be run under a current Linux kernel. See http://kerneltrap.org/Linux/Dusting_Off_the_0.01_Kernel

Any way you look at it, Linux 0.01 is still alive and will be for as long as people care about it.

It has happened, although the case is slightly more complicated than that.

"Linux is evolution, not intelligent design."

-- Linus Torvalds

(This quote seems to be genuine, I haven't been able to track down a reference though.)

Sun already have ZFS in Solaris, Nexenta, FreeBSD, OS X, and FUSE, I don't think they're in much danger of it fading into obscurity just yet.

In other news, HAMMER is shaping up nicely, and neatly sidesteps pretty much all license concerns.

Ahhh those kids, always looking for new and shiny things. I am still running 0.01. If ain't break don't touch it.

Yes, and that's still much better than when much worse mistakes are made in proprietary systems. At least in the open source case the mistake *was* found, and because of the heterogeny of the open source space, it only affected "some" distributions, and the fix was released in a matter of hours. I haven't heard of a single high profile target compromised because of that error. Many Windows bugs have affected over 80% of the world's desktops at a time, and there have been *plenty* of those, not just one.

And if you want to play this game, why not bring up the case where an actual blackhat tampered with the Linux upstream CVS repository and his clever backdoor was still caught before it was even released. http://kerneltrap.org/node/1584 Just because a single error occured in Debian's process does not damn the entire open source world.

I'm pretty sure submitted code is reviewed, so you'd have to be pretty clever.

It has been tried before. In this case, someone attempted to use the common C programming mistake of using the assignment operator instead of the comparison operator to backdoor the kernel.

This has been tried before. Have a look at this Linux kernel backdoor attempt.

If you don't think these are the best-supported framebuffers Linux has ever had, provide a counterargument.

Via enables better framebuffer support on their hardware. Intel re-architects the framebuffer/X interface for all hardware (theirs included) to remove the horrible Xorg/fbdev mess that has been festering for years.

http://kerneltrap.org/node/8242

I only read about half the thread or so, but could you point to where gNewSense points users to Ubuntu's repositories (or the message that says so)?

RMS came onto the OpenBSD-misc mailing list in January to inform the subscribers that he had deemed OBSD to be non-free. Much wonderment ensued.

Any chance that the reset packets could be sent from someone else? If AT&T can send a reset packet that looks like it's from the person on BT you are communicating with, what's to stop other users from sending a similar packet[?]

1. source IP
2. source port
3. destination IP [1]
4. destination port [2]
5. sequence number [3]

So don't hold your breath. If they can tell what hosts you are communicating with, they can determine everything else. They are either at an ISP or a backbone provider (or in your basement, if you're the paranoid type).

1. a freebie, we presume the forger knows the IP of the machine to interfere with
2. the destination port is straightforward to guess
3. the sequence number is easy to fake out due to widespread use of TCP size windows.

For one thing, we won't have to listen to RMS whining about it every time someone mentions the current version of OpenOffice.

For one thing, we won't have to listen to RMS whining about it every time someone mentions the current version of OpenOffice.

Most everybody moved to network printing years ago. It's working out fine.

In fact, a lot of direct attached peripherals can go away. Gigabit networks are fine for most stuff you used to attach devices directly to your PC for.

HP's linux support isn't really all that good. Most of what I've seen has been developed by third-parties.

HP supports linux. They have for a long time. Kernel.org runs on servers donated by HP and they have since 2001. Third party support for HP gear is also strong as you note. I only wish they'd wake up and start using it for their web server. Their site is hideous and slow, and for the most part their web stuff is IE only. Other than that, good on them.

Let me quote for you from a history article:

Fourth Generation:

As it become more apparent that the hardware needed an upgrade, Peter began to think about preparing a request to Hewlett-Packard for new hardware. Before he even made his request, HP contacted him basically saying, "hey, we noticed that you guys have been kind of struggling lately, what do you need?" Peter provided them with his wish list, and within two weeks the decision was made and new hardware was on the way. Peter noted, " HP came to us from a quite high level. They have been absolutely great."

Matt Taggart, part of the R&D lab within HP's Open Source & Linux Organization, noted that HP is a large company and that the different donations to kernel.org actually came from different divisions. "There are plenty of people in HP that recognize the value that kernel.org provides and that benefit (both directly and indirectly through HP's customers) from having it perform well," he explained. "This time the donation came for HP's Open Source and Linux Operation R&D Lab, but in the past they have come from other places such as the Industry Standard Server Division (the folks that do ProLiant)." He went on to add, "HP's IT organizations also use Linux and are big users of kernel.org, so it benefits them as well."

As for why HP has made these donations, Matt explained, "when possible, HP likes to help Free and Open Source software projects at the source. For example, if HP wants to contribute driver fixes for a piece of equipment that we ship, it is a better use of our time to work at the kernel.org level rather than duplicating effort by working individually with each distributor (or not being able to work with some at all). Providing kernel.org hardware is an easy way for us to give back to the project that has helped save us a lot of effort."

'nuff said.

http://kerneltrap.org/node/2450/7217

"The Problem:

So, the basic problem here is, the kernel ( 2.6 ) can just address 1 GB of virtual addresses, which can translate to a maximum of 1 GB of physical memory. This is because the kernel directly maps all available kernel virtual space addresses to the available physical memory."

"Solutions:

http://web.archive.org/web/20020313185718/http://strasbourg.linuxfr.org/jl3/features-2.3-2.html

"Originally HIGHMEM was called BIGMEM and BIGMEM seen the light in kernel 2.3.16."

This is the Kernel patch I was talking about. The IA64 Kernel, that Alan Cox was the maintainer for SGI was nothing less than a brilliant peice of work, however it left the IA32 world behind, and a few linux vendors were left with the HIGHMEM patch, which slowed the machine's down due to having to use a segmented (1GB segment ) address space. It easily trimmed off 30% of the horsepower, but since it was running SAP, most of the horsepower was wasted anyway.

The problem will be back when, for IA64, when the SAP database requirements grow beyound 16GB, and the MMU chips will need a diffrent type of patch.

Dont think for a second, that both Alan Cox's work on the SGI/IA64 port was anything less that brilliant, nor that Andrea Arcangeli's work was anything less than brilliant either. It was an enhancement that came at a cost.

I'm using a Gateway 2000 P6301:

http://support.gateway.com/s/Mobile/2007/Godzilla/1014776R/1014776Rsp2.shtml

It has only VGA out (yep, no HDMI or DVI or other connectors). I have a separate LCD at home that I'd like to "span" or expand my desktop to, but I don't want a "single" screen simply duplicated to the LCD. I want to put on the external LCD any virtual desktop or app of my choosing.

A year or 2 ago, I thought I read in LXF about 2 or more Xserver options to edit by hand to achieve this. There were/are commercial implementations, too. But, I misplaced those mags and can't find the archives online.

My laptop currently is running PCLinux OS 2008, KDE 3.5.8.

Video controller information:

Intel® Graphics Media Accelerator X3100
Up to 384 MB of Dynamic Video Memory

The external LCD is recognized only if connected during boot up. After booting, if the LCD had not been connected, it simply is not recognized, doesn't light up, and I have to connect it and then power cycle if I want to use the external LCD

Currently, I'm looking at:

http://www-128.ibm.com/developerworks/linux/library/os-mltihed/index.html

http://kerneltrap.org/mailarchive/openbsd-misc/2007/9/2/153902

Can you offer me any xorg or advice?

Thanks!

Interestingly, if you look down the thread a bit, the list of problematic GPLONLY symbols pops up. A follow-up states that ndiswrapper already has a workqueue implementation, so those symbols could be safely not used (of course it's better to use shared code than a private copy to do the same thing), and the use of task_nice() and be worked around. The USB stuff is unfortunate, but removing that would (presumably) only make ndiswrapper not support USB wireless dongles. That's certainly a problem for some people, but not for others. The possibility of doing the USB support in userspace is also discussed, but currently there's no way to register a network device from outside the kernel, so that could be difficult.

Interestingly, if you look down the thread a bit, the list of problematic GPLONLY symbols pops up. A follow-up states that ndiswrapper already has a workqueue implementation, so those symbols could be safely not used (of course it's better to use shared code than a private copy to do the same thing), and the use of task_nice() and be worked around. The USB stuff is unfortunate, but removing that would (presumably) only make ndiswrapper not support USB wireless dongles. That's certainly a problem for some people, but not for others. The possibility of doing the USB support in userspace is also discussed, but currently there's no way to register a network device from outside the kernel, so that could be difficult.

From: Linus Torvalds <torvalds@...>
Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols
Date: Feb 29, 1:07 pm 2008
 
On Fri, 29 Feb 2008, Zan Lynx wrote:
>
> The Linux kernel itself will load proprietary modules. It does not as a
> general rule, but it will.
 
.. and it doesn't export GPLONLY modules to them.
 
How stupid do you have to be to not understand that?
 
        Linus

Actually, no.

Adding a firmware password to my PPC Macs puts them into a heightened security mode that turns off Firewire DMA (and was tested specifically with the hack you referenced). I would expect the Intel units to have this feature also. And the new Linux firewire driver tackles the DMA vulnerability issue too.

What I've read on the subject so far indicates that most or all Firewire chipsets allow operation without DMA, and that it is possible to secure the DMA modes by programming the memory controller to restrict access to specific buffers

FWIW, Apple was similarly "cagey" (actually silent) on the issue, but at least gave us the ability to secure the port through openfirmware.

What I would worry about more are the DMA interfaces that no one is discussing re: security... PCMCIA/PCCard and other hot-swappable ports (PCI-X? eSATA?) that support bus mastering. I'm pretty sure that non-USB-implemented CF slots are a risk.

GREAT article - it is interesting for a non-programmer to read this type of technical detail, presented in an understandable way. For me, right at the edge of my theoretical-only knowledge. A detailed summary, I guess. (oxymoron)

Similar article on NetBSD: Waving the flag: NetBSD developers speak about version 4.0 (1/30/2008)

Linux focused links:

Current discussion:
LWN: Kernel
KernelTrap
KernelNewbies: Summary of Linux Changes
---
The Wonderful World of Linux series are excellent history - in-depth for outsiders:
WWOL 2.2
WWOL 2.4
WWOL 2.6
---
Towards Linux 2.6 - A look into the workings of the next new kernel(2003)
Kernel Comparison: Linux (2.6.22) versus Windows (Vista)(2007)

> Linus named it FreakOS I believe. It was someone else who convinced him to rename it to Linux.

Freax, actually. Ari Lemmke was the one who came up with the name Linux. I think it's a good thing, too, personally.

And on a final unrelated note, to counter Torvald's argument that HFS is crap, we've been reading for nearly a year that Apple is ready to adapt ZFS. Once MacOS defaults to ZFS, it'll trounce any existing form of ext3. He really should be comparing the merits of ext3 against ZFS, the future, not the past.

Oh, really?

Did you forget about assignment versus equality, perhaps? http://kerneltrap.org/node/1584

Are the FreeBSD/Mach developers still incompetent now? http://kerneltrap.org/node/6506