Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Christian Trefzer wrote: On Wed, Aug 09, 2006 at 12:01:42AM -0400, David Masover wrote: A warning isn't good? Would you rather it be an error? Of course not. It merely appears inconsistent to offer a root fs choice that may cause severe problems at bootup time. When I went to install my first SuSE (brand-new 6.1 at that time) I looked up the huge printed manual: what are my options? OK there weren't many at the time ; ) But there was the >1023cyl problem, being a careful guy I opted for a separate /boot at the start of the disk, for example. Better safe than sorry. Right. Now say I carefully weigh different aspects of different solutions, only to find out that my decision was "not so good" and will possibly cause problems _unless_ I play around with strange mount options that _disable_ some of the features supporting my decision. Right, except you can still use a separate /boot to isolate those problems. I bet Reiser4 makes this easier, by the way -- it could make the root dir and anything in /boot be much simpler. I seem to remember that Grub couldn't deal with tail packing in ReiserFS, for one... Knowing trouble lies ahead of course is better than just running into it : ) If it's avoidable, yes. Otherwise, depends. If you had a terminal illness, would you rather know about it, or would you rather just drop dead one day? Not an easy question... Ok, never mind, that's irrelevant. Some people would like to test Grub's XFS support... Sure thing. But those might not want to do this on their production machine, anyway, and test something more bleeding-edge than what distros ship at the time. Presuming there is ongoing development, that is. Hmm, well, I like to be able to choose bleeding-edge from the same install disk as I choose production. It means I only need the one install disk, and I can pick and choose which bleeding-edge features I want; everything else will go as smoothly as the production install. It's not necessarily broken, just potentially unreliable, and difficult to work with (you have to set arcane mount options or somesuch). Same for ReiserFS3, by the way. All that, especially "unreliable", is not something your average user is likely to accept. [...] So what a distro installer wants to do is remove all the options from anything but "expert mode" that might cause the slightest hickup. Expert mode is overkill, though, especially for this. If you want to shield the user from absolutely everything that could possibly go wrong, that means you can't let the user do ANYTHING. After all, it's easy enough to wipe out their Windows partition, and all they get is a warning... I mean, such an "uber-newbie" mode would be nice, but it's not anything that any install system, including Windows and OS X, has ever done. The only way we've come close is preinstalling, which would be the best way to get Linux into the hands of users, by the way. Really, while Grub is useful, it's a rather large duplication-of-code effort. XOSL is even moreso, especially considering it doesn't support Linux or multiboot natively -- it must boot Grub or Lilo in order to run Linux or HURD. Why aren't we using kexec for this already? This is way beyond my knowledge, sorry. But I like kexec a lot, just wonder how to get to the point where kexec can be used _without_ linux up and running already... We can't, but "linux up and running" doesn't take much more time than Grub or XOSL, if we're talking about some minimal initrd/initramfs situation. For instance, LinuxBIOS+kexec would be an order of magnitude faster than anything else, because LinuxBIOS can already be faster than a standard PC BIOS anyway, and this lets you skip a bootloader as well. It would also give you the option of not runnning kexec if the first kernel booted was the right version to run a particular distro. For instance, I might boot straight into my Gentoo, but kexec a boot CD, an Ubuntu, or a Windows. The nice thing that this would give us over Grub and others is the ability to boot off any device Linux supports, as well as have true scriptability at boot time (menu.lst doesn't really count). Imagine this: A cheap, lightweight laptop, without a working hard drive, but with a small amount of flash memory and a fast wireless card. Linux loads off the flash, which includes OpenVPN, keys and all, and sets up a VPN connection, then mounts an NFS root over the VPN. A quick check of /boot can either tell it that the contents of the flash drive are the most recent version -- or, if they aren't, the flash drive gets updated, then we kexec the new kernel and start over. Saves us a reboot. It's basically a diskless thin client that works from any open wireless access point, although it does wreak havoc on whatever bandwidth you give it. Alternatively, if you're only using it in one area, you could set it up with WPA keys instead of OpenVPN, although the VPN does do other nice t
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Wed, Aug 09, 2006 at 12:01:42AM -0400, David Masover wrote: > A warning isn't good? Would you rather it be an error? Of course not. It merely appears inconsistent to offer a root fs choice that may cause severe problems at bootup time. When I went to install my first SuSE (brand-new 6.1 at that time) I looked up the huge printed manual: what are my options? OK there weren't many at the time ; ) But there was the >1023cyl problem, being a careful guy I opted for a separate /boot at the start of the disk, for example. Better safe than sorry. And if there had been a choice in terms of file systems (ext2 was the only way afair) there would have been a decision as well. Now say I carefully weigh different aspects of different solutions, only to find out that my decision was "not so good" and will possibly cause problems _unless_ I play around with strange mount options that _disable_ some of the features supporting my decision. Knowing trouble lies ahead of course is better than just running into it : ) > Some people would like to test Grub's XFS support... Sure thing. But those might not want to do this on their production machine, anyway, and test something more bleeding-edge than what distros ship at the time. Presuming there is ongoing development, that is. > It's not necessarily broken, just potentially unreliable, and > difficult to work with (you have to set arcane mount options or > somesuch). Same for ReiserFS3, by the way. All that, especially "unreliable", is not something your average user is likely to accept. People have been cursing the whole x86-pc hardware for the mess that mainstream software (M$ mainly, but no need to copy their mistakes) has been for the past two decades. I've been asked by folks more than once if switching to a mac will ease their pain. So what a distro installer wants to do is remove all the options from anything but "expert mode" that might cause the slightest hickup. > Really, while Grub is useful, it's a rather large duplication-of-code > effort. XOSL is even moreso, especially considering it doesn't > support Linux or multiboot natively -- it must boot Grub or Lilo in > order to run Linux or HURD. Why aren't we using kexec for this > already? This is way beyond my knowledge, sorry. But I like kexec a lot, just wonder how to get to the point where kexec can be used _without_ linux up and running already... > It's called "backup and restore." Or did you have a different idea > for how to convert an existing installation to another root FS, or do > a fresh installation without nuking your partitions anyway? Well, there is convertfs, fsconvert (which i.e. _is_ backup&restore), parted, etc. There are ways, some are safe, most are not. But I am afraid we have gone way OT by now. What I had in mind all the way basically was the distro user / end user experience which should be as uncomplicated as possible, while still leaving choices. But when it comes to "advanced" file systems, these choices come at the price of a more sophisticated setup or lack of reliability, as you already pointed out. But how do you explain to a linux newbie: use ext2|3 for / due to bootloader issues _or_ something funky, yet with funkyness partly turned off for bootloader compatibility, _or_ use a tiny ext2 /boot and feel free to fsck&mount as you damn please. Most people just don't care anyway, and those who do will want to know why. And telling them that otherwise it won't work (without extra care) yields the question, "why not?", and you might _not_ want to try explaining the entire situation from within the installer help text. Or maybe that would be the way to go? Who knows how much people actually read in the end, before they just quit - worrying, deciding, or even installing the thing at all. And now, go easy on me! This was never intended as a debate of colliding opinions - call it brainstorming : ) Kind regards, Chris pgpsSTvFCVQnV.pgp Description: PGP signature
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Christian Trefzer wrote: On Mon, Aug 07, 2006 at 01:09:42PM -0400, David Masover wrote: Christian Trefzer wrote: Few people keep a 32MB ext2 for /boot purposes these days, so it really is imperative that grub can read kernel images off a reiser4 /. I think there are patches, but I do keep a 32 meg ext3 for /boot, because it seems like no matter what FS I choose, there's some sort of caveat involving Grub. I know when installing XFS as a root FS on Ubuntu, it talks about Grub problems... New installations is what I had in mind there. People see they could use something fancy, but their bootloader-du-jour won't take it. Bummer. The warning message is the only thing keeping folks from running into a broken installation. No good. A warning isn't good? Would you rather it be an error? Some people would like to test Grub's XFS support... It's not necessarily broken, just potentially unreliable, and difficult to work with (you have to set arcane mount options or somesuch). Same for ReiserFS3, by the way. Really, while Grub is useful, it's a rather large duplication-of-code effort. XOSL is even moreso, especially considering it doesn't support Linux or multiboot natively -- it must boot Grub or Lilo in order to run Linux or HURD. Why aren't we using kexec for this already? I mean, having Grub support everything would be nice, but if you're reformatting anyway, I don't think it's that imperative. Yeah, _if_ you are s.o. who knows how to turn a partition table upside down without losing a single bit of data. It's called "backup and restore." Or did you have a different idea for how to convert an existing installation to another root FS, or do a fresh installation without nuking your partitions anyway?
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Hello David, Tuesday, August 8, 2006, 2:05:23 AM, you wrote: > Under what, though? I don't want MS crap on my OS X (need that for work > ATM), and I can't imagine they've ported it to Linux. I have no reason > to boot Windows except for games, and if I was going to do that, I may > as well shrink my Windows partition to make room for a native install. "VMware has announced a product designed to enable Mac OS X users to run multiple PC operating systems while Microsoft is putting a halt to a version of its Virtual PC software for Intel-based Macs." http://www.osnews.com/story.php?news_id=15417 It seems that: 1) ms has virtual pc for macs. 2) vmware will have. -- Best regards, Maciej
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On 8/8/06, Christian Trefzer <[EMAIL PROTECTED]> wrote: Grub is a bootloader and as such should (as an optimum) be able to grab kernels off of any fs. I guess patches are accepted by upstream developers? Grub v1 (The one we all know) is alpha status according to their devs. Its no longer under active development - in favour of v2. AFAIK, they have stopped accepting patches for it, and they have no plans to release v2 in the near future. and I don't think it is even compilable That doesn't stop mainline distros to accept namesys' patch anyway. Sarath
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Mon, Aug 07, 2006 at 01:09:42PM -0400, David Masover wrote: > Christian Trefzer wrote: > > Few people keep a 32MB ext2 for /boot purposes these days, so it > > really is imperative that grub can read kernel images off a reiser4 > > /. > > I think there are patches, but I do keep a 32 meg ext3 for /boot, > because it seems like no matter what FS I choose, there's some sort of > caveat involving Grub. I know when installing XFS as a root FS on > Ubuntu, it talks about Grub problems... New installations is what I had in mind there. People see they could use something fancy, but their bootloader-du-jour won't take it. Bummer. The warning message is the only thing keeping folks from running into a broken installation. No good. > I mean, having Grub support everything would be nice, but if you're > reformatting anyway, I don't think it's that imperative. Yeah, _if_ you are s.o. who knows how to turn a partition table upside down without losing a single bit of data. Even then, it is quite a hassle to move the start of a partition 4 cylinders up to make room for an all-compatible ext2 /boot ; ) Grub is a bootloader and as such should (as an optimum) be able to grab kernels off of any fs. I guess patches are accepted by upstream developers? Kind regards, Chris pgpcCiJHSyAXR.pgp Description: PGP signature
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Mon, 2006-08-07 at 20:05 -0400, David Masover wrote: > Maciej Sołtysiak wrote: > > Hello David, > > > > Tuesday, August 8, 2006, 1:23:01 AM, you wrote: > >> Sounds good. I don't have an ubuntu to test with at the moment, though. > > Well, both MS Virtual PC and VMWare are free of charge, so installing > > is a real snap. > > Under what, though? I don't want MS crap on my OS X (need that for work > ATM), and I can't imagine they've ported it to Linux. I have no reason > to boot Windows except for games, and if I was going to do that, I may > as well shrink my Windows partition to make room for a native install. > > Which would be fine, but it's a lot of work when I don't run Ubuntu > normally. > > I'd be willing to test on the one Ubuntu server I run, but it's across > the country until next week, and also work-critical. > > >> Not to nitpick, but isn't that emulation? Or have they actually done > >> real virtualization yet? > > I don't know the differences, can you shed some light? AFAICS M$ will > > be shipping Virtual PC with Vista to allow people run older software > > under virtual machines. (be it virtualized or emulated) > > Still hard to say. > > Virtualization splits up the real hardware. It's like a scheduler, only > for OSes. Emulation is more like an interpreter -- it reads each > instruction and then executes something that does the same thing. > Emulation can work from any arch to any arch, so Rosetta (allowing PPC > OS X apps to run on OS X86) is emulation. > > Emulation is usually at least 2x slower than native. Virtualization > usually approaches native for CPU stuff, but at least disk IO and > graphics usually have to be emulated -- so no 3D acceleration, so no > games under a guest OS. > > If MS wanted to do the best possible thing for their consumers, they'd > give you a free XP under VirtualPC with Vista, and actually do > virtualization. If M$ wanted to make it even more likely for people to > want to upgrade to Vista, they might deliberately make it cost tons of > money and make it emulation, so that XP looks slower, and native Vista > apps look so much faster that people complain until everything works on > Vista. > > > If Virtual PC is emulation, maybe Virtual Server 2005 R2 (also free of > > charge) is virtualizaton. > > I have no idea what Virtual Server is. There are many forms of virtualization see 1, one of them being emulation. VMware and virtual pc do emulation but if possible they will pass instruction directly to the hardware without emulating vias a hypervisor. Good reading on virtualization on 2. Greets Sander [1] http://en.wikipedia.org/wiki/Virtualization [2] http://www.kernelthread.com/publications/virtualization/
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Maciej Sołtysiak wrote: Hello David, Tuesday, August 8, 2006, 1:23:01 AM, you wrote: Sounds good. I don't have an ubuntu to test with at the moment, though. Well, both MS Virtual PC and VMWare are free of charge, so installing is a real snap. Under what, though? I don't want MS crap on my OS X (need that for work ATM), and I can't imagine they've ported it to Linux. I have no reason to boot Windows except for games, and if I was going to do that, I may as well shrink my Windows partition to make room for a native install. Which would be fine, but it's a lot of work when I don't run Ubuntu normally. I'd be willing to test on the one Ubuntu server I run, but it's across the country until next week, and also work-critical. Not to nitpick, but isn't that emulation? Or have they actually done real virtualization yet? I don't know the differences, can you shed some light? AFAICS M$ will be shipping Virtual PC with Vista to allow people run older software under virtual machines. (be it virtualized or emulated) Still hard to say. Virtualization splits up the real hardware. It's like a scheduler, only for OSes. Emulation is more like an interpreter -- it reads each instruction and then executes something that does the same thing. Emulation can work from any arch to any arch, so Rosetta (allowing PPC OS X apps to run on OS X86) is emulation. Emulation is usually at least 2x slower than native. Virtualization usually approaches native for CPU stuff, but at least disk IO and graphics usually have to be emulated -- so no 3D acceleration, so no games under a guest OS. If MS wanted to do the best possible thing for their consumers, they'd give you a free XP under VirtualPC with Vista, and actually do virtualization. If M$ wanted to make it even more likely for people to want to upgrade to Vista, they might deliberately make it cost tons of money and make it emulation, so that XP looks slower, and native Vista apps look so much faster that people complain until everything works on Vista. If Virtual PC is emulation, maybe Virtual Server 2005 R2 (also free of charge) is virtualizaton. I have no idea what Virtual Server is.
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Hello David, Tuesday, August 8, 2006, 1:23:01 AM, you wrote: > Sounds good. I don't have an ubuntu to test with at the moment, though. Well, both MS Virtual PC and VMWare are free of charge, so installing is a real snap. > Not to nitpick, but isn't that emulation? Or have they actually done > real virtualization yet? I don't know the differences, can you shed some light? AFAICS M$ will be shipping Virtual PC with Vista to allow people run older software under virtual machines. (be it virtualized or emulated) If Virtual PC is emulation, maybe Virtual Server 2005 R2 (also free of charge) is virtualizaton. -- Best regards, Maciej
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Maciej Sołtysiak wrote: Hello David, hi I have built today an r4-patched ubuntu kernel package (yes, debs!) Sounds good. I don't have an ubuntu to test with at the moment, though. Please note, that this is done all under virtualization (Microsoft Virtual PC). Not to nitpick, but isn't that emulation? Or have they actually done real virtualization yet?
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Hello David, Monday, August 7, 2006, 7:09:42 PM, you wrote: > I mean, having Grub support everything would be nice, but if you're > reformatting anyway, I don't think it's that imperative. I have come up to that conclusion too. If someone would be getting an r4-enabled kernel on an already installed system they would not care much for grub support unless they have only one root partition. I have built today an r4-patched ubuntu kernel package (yes, debs!) using edgy eft's git-based build system, which allows me to build ubuntu kernels! Yes, with all the stuff they have in there, with all the configuration versions they support (-386, -k7, -server, etc...) I booted one and I will try to create an r4 partition later today. Please note, that this is done all under virtualization (Microsoft Virtual PC). -- Best regards, Maciej
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Christian Trefzer wrote: On Sun, Aug 06, 2006 at 04:23:16PM +0200, Maciej Sołtysiak wrote: There also is an issue with grub. The kernel alone is fine for creating partitions (or loop devices) but with grub not patched we can't install boot partitions. No biggy, I guess, but still a problem. Few people keep a 32MB ext2 for /boot purposes these days, so it really is imperative that grub can read kernel images off a reiser4 /. I think there are patches, but I do keep a 32 meg ext3 for /boot, because it seems like no matter what FS I choose, there's some sort of caveat involving Grub. I know when installing XFS as a root FS on Ubuntu, it talks about Grub problems... I mean, having Grub support everything would be nice, but if you're reformatting anyway, I don't think it's that imperative.
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Sun, Aug 06, 2006 at 04:23:16PM +0200, Maciej Sołtysiak wrote: > I tried to create a kernel package with reiser4 for ubuntu-server (dapper) > They ship a 2.6.15 (heavily modified) kernel upon which the current > reiser4-for-2.6.17-3.patch applies fine but unfortunately miscompiles, eg. > fs/reiser4/plugin/file_ops_readdir.c: In function 'llseek_common_dir': > fs/reiser4/plugin/file_ops_readdir.c:486: warning: implicit declaration of > function 'mutex_lock' > fs/reiser4/plugin/file_ops_readdir.c:486: error: 'struct inode' has no member > named 'i_mutex' > fs/reiser4/plugin/file_ops_readdir.c:508: warning: implicit declaration of > function 'mutex_unlock' > fs/reiser4/plugin/file_ops_readdir.c:508: error: 'struct inode' has no member > named 'i_mutex' > > I bet these are trivial to fix and I will try to do this but my time > constraints > currently prevent me from doing that. Guess these won't be so easy, afaik 2.6.15 lacks the semaphore->mutex transition. > There also is an issue with grub. The kernel alone is fine for creating > partitions > (or loop devices) but with grub not patched we can't install boot partitions. > No biggy, > I guess, but still a problem. Few people keep a 32MB ext2 for /boot purposes these days, so it really is imperative that grub can read kernel images off a reiser4 /. > I could create a vanilla + reiser4 kernel package easily but that would be > stripped > off of the important dapper/debian patches and that is a no-no for dapper > users, I guess. > At least for non-guru freaks who run their own, modified kernels. Sure. The best thing might be to back-port "internal" fixes in fs/reiser4/ to reiser4-for-2.6.15-x so the API calls match the kernel. Patching 2.6.15 with a 2.6.17 patch is a no-no. But you _are_ taking a step forward, and your effort is appreciated : D Kind regards, Chris pgpaKpM0N5nTR.pgp Description: PGP signature
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
> I know it is very easy to create ubuntu kernel packages (I have done a few) > I might try to do one for current dapper kernel for i386. But it would have > to wait due to time my personal constraints (projects, etc.) Answering myself... I tried to create a kernel package with reiser4 for ubuntu-server (dapper) They ship a 2.6.15 (heavily modified) kernel upon which the current reiser4-for-2.6.17-3.patch applies fine but unfortunately miscompiles, eg. fs/reiser4/plugin/file_ops_readdir.c: In function 'llseek_common_dir': fs/reiser4/plugin/file_ops_readdir.c:486: warning: implicit declaration of function 'mutex_lock' fs/reiser4/plugin/file_ops_readdir.c:486: error: 'struct inode' has no member named 'i_mutex' fs/reiser4/plugin/file_ops_readdir.c:508: warning: implicit declaration of function 'mutex_unlock' fs/reiser4/plugin/file_ops_readdir.c:508: error: 'struct inode' has no member named 'i_mutex' I bet these are trivial to fix and I will try to do this but my time constraints currently prevent me from doing that. There also is an issue with grub. The kernel alone is fine for creating partitions (or loop devices) but with grub not patched we can't install boot partitions. No biggy, I guess, but still a problem. I could create a vanilla + reiser4 kernel package easily but that would be stripped off of the important dapper/debian patches and that is a no-no for dapper users, I guess. At least for non-guru freaks who run their own, modified kernels. -- Best regards, Maciej
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On 03/08/06, Maciej Sołtysiak <[EMAIL PROTECTED]> wrote: >>It's quite late for inclusion in the next Ubuntu release, but who knows. Maybe it is not, it's a playground, Mark would not hesitate to postpone Edgy's release if it requires polishing the whole thing due to "edgy" features. > Could you contact him for us, and ask? It is more convincing when users > ask. Hehe, Hans, I tried contacting him. On his website he points to his secratary Claire. She's on maternity leave, so another girl, also named Claire replies. Here's what I got for asking about Mark collaborating with Hans: " Hi Maciej Thank you for your e-mail and interest in Ubuntu. Unfortunately, this is not something we can help you with. I hope that you are able to find the help you require elsewhere. kind regards Claire " God damn it, secrataries... I haven't found Mark's email address anywhere, did anyone have? Maybe it is better to get in contact with the 2 people from this link. https://wiki.ubuntu.com/Reiser4 David is a former gentoo users and was the one who maintained the love-sources. The only e-mail address I could find for him was [EMAIL PROTECTED] (his jabber but it looks ok. Greets Sander
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
>>It's quite late for inclusion in the next Ubuntu release, but who knows. Maybe it is not, it's a playground, Mark would not hesitate to postpone Edgy's release if it requires polishing the whole thing due to "edgy" features. > Could you contact him for us, and ask? It is more convincing when users > ask. Hehe, Hans, I tried contacting him. On his website he points to his secratary Claire. She's on maternity leave, so another girl, also named Claire replies. Here's what I got for asking about Mark collaborating with Hans: " Hi Maciej Thank you for your e-mail and interest in Ubuntu. Unfortunately, this is not something we can help you with. I hope that you are able to find the help you require elsewhere. kind regards Claire " God damn it, secrataries... I haven't found Mark's email address anywhere, did anyone have? -- mks
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Marcel Hilzinger wrote: >Am Donnerstag, 3. August 2006 10:55 schrieb Marcel Hilzinger: > > >>Am Dienstag, 1. August 2006 23:59 schrieb Sander Sweers: >> >> >>>On Tue, 2006-08-01 at 23:12 +0200, Maciej Sołtysiak wrote: >>> >>> >>[...] >> >> >> >>>Are there any on the list who know of rpm's for Suse/Redhat/Mandrake >>>that include reiser4? >>> >>> >One more idea: > >The next release of Ubuntu is a "playground release". Hans, perhaps you should >have a meeting with Mark Shuttleworth. Reiser4 inclusion in Linspire was a >big step, but Linspire has not really a community. If you get Reiser4 >included in the next Ubuntu release (and can make it rock stable then!), you >do not have to bother about Fedora or Suse... > >It's quite late for inclusion in the next Ubuntu release, but who knows. > > Could you contact him for us, and ask? It is more convincing when users ask. Hans
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Am Donnerstag, 3. August 2006 10:55 schrieb Marcel Hilzinger: > Am Dienstag, 1. August 2006 23:59 schrieb Sander Sweers: > > On Tue, 2006-08-01 at 23:12 +0200, Maciej Sołtysiak wrote: > > [...] > > > Are there any on the list who know of rpm's for Suse/Redhat/Mandrake > > that include reiser4? One more idea: The next release of Ubuntu is a "playground release". Hans, perhaps you should have a meeting with Mark Shuttleworth. Reiser4 inclusion in Linspire was a big step, but Linspire has not really a community. If you get Reiser4 included in the next Ubuntu release (and can make it rock stable then!), you do not have to bother about Fedora or Suse... It's quite late for inclusion in the next Ubuntu release, but who knows. -- Üdvözlettel -- Mit freundlichen Grüssen, Marcel Hilzinger
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Am Dienstag, 1. August 2006 23:59 schrieb Sander Sweers: > On Tue, 2006-08-01 at 23:12 +0200, Maciej Sołtysiak wrote: [...] > Are there any on the list who know of rpm's for Suse/Redhat/Mandrake > that include reiser4? Suse excluded reiser4 from 10.1 because they want to keep the kernel "cleaner" than in previous versions. Il ask what's the status with 10.2, but I think it's still left out. With the new build-server (http://en.opensuse.org/Build_Service) it shouldn't be too hard to build packages. Also Suse supports now special packages for kernel-modules, which can even survive a kernel-update, if the API does not change. But I see another important point: Reiser4 is very fast if you have more than one reiser4 partition. But: most home users make one or two reiser4 partitions for testing purpose. Until the whole system does not run on reiser4 the speed improvement cannot be felt 100%. So community members should make pressure at Suse, Fedora, Mandriva to get reiser4 supported by the distro. -- Üdvözlettel -- Mit freundlichen Grüssen, Marcel Hilzinger
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Sander Sweers wrote: > > >With the approval of Namesys I would like to add a new entry to the wiki >frontpage. > It would be very appreciated.
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Tue, 2006-08-01 at 23:12 +0200, Maciej Sołtysiak wrote: > Hello Sander, Hey > > Tuesday, August 1, 2006, 8:10:34 PM, you wrote: > > Yes, and in case of gentoo there are already people maintaining an > > ebuild which pull in r4 on the wiki. > > http://gentoo-wiki.com/HOWTO_Reiser4_With_Gentoo-Sources > Debian has reiser4progs and kernel-patch-2.6-reiser4: Nice :) > - stable: 20040813-6 > - testing: 20050715-1 > - unstable: 20050715-1 Ouch :( It is in serious need of updating. With the approval of Namesys I would like to add a new entry to the wiki frontpage. I would be someting like "Get reiser4 now" or "Howto install reiser4". Under that we detail the steps to get kernels for distros which include reiser4 and how to patch it yourself. > I know it is very easy to create ubuntu kernel packages (I have done a few) > I might try to do one for current dapper kernel for i386. But it would have > to wait due to time my personal constraints (projects, etc.) Great :) Are there any on the list who know of rpm's for Suse/Redhat/Mandrake that include reiser4? Greets Sander
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
Hello Sander, Tuesday, August 1, 2006, 8:10:34 PM, you wrote: > Yes, and in case of gentoo there are already people maintaining an > ebuild which pull in r4 on the wiki. > http://gentoo-wiki.com/HOWTO_Reiser4_With_Gentoo-Sources Debian has reiser4progs and kernel-patch-2.6-reiser4: - stable: 20040813-6 - testing: 20050715-1 - unstable: 20050715-1 Very old patches. Also the patch descriptions says: "WARNING: this software is to be considered usable but its deployment in production environments is still not recommended. Use at your own risk." I know it is very easy to create ubuntu kernel packages (I have done a few) I might try to do one for current dapper kernel for i386. But it would have to wait due to time my personal constraints (projects, etc.) -- Best regards, Maciej
Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Tue, 2006-08-01 at 13:28 +0200, Maciej Sołtysiak wrote: > Hello David, > > Monday, July 31, 2006, 11:46:34 PM, you wrote: > > You must be new here... > ;-) > > I wanted to point out that because: > > Options B and C are all that ever seems to happen when reiserfs-list and > > lkml collide. > > and: > > The speed of a nonworking program is irrelevant. > > The cost-effectiveness of an impossible solution is irrelevant. > > maybe the more important thing is to allow people use r4 on their own > (rpms, debs, apt/gentoo/repositories, etc.) better, than to push that hard > for kernel inclusion. > Yes, and in case of gentoo there are already people maintaining an ebuild which pull in r4 on the wiki. http://gentoo-wiki.com/HOWTO_Reiser4_With_Gentoo-Sources WHen you make it easy for people to use reiser4 by providing ebuilds, rpm's or deb's more users will be tempted to try out reiser4 who would normally not be able or willing to patch the kernel. Maintaning an ebuild for example is easy. And adding in another patch to a kernel deb/rpm should also not be too difficult. It will take some time to do each month but sacrificing a few hours to update these to me would be worth it. Maybe the reiser cummunity can help out the namesys devs? Greets Sander
Re: reiser4 can now bear with filled fs, looks stable to me...
Hello David, Monday, July 31, 2006, 11:46:34 PM, you wrote: > You must be new here... ;-) I wanted to point out that because: > Options B and C are all that ever seems to happen when reiserfs-list and > lkml collide. and: > The speed of a nonworking program is irrelevant. > The cost-effectiveness of an impossible solution is irrelevant. maybe the more important thing is to allow people use r4 on their own (rpms, debs, apt/gentoo/repositories, etc.) better, than to push that hard for kernel inclusion. Currently the r4 patch is very easy to apply, you can apply it on top of heavily patched kernels with no or little fuzz, which is very good. But, as Hans wrote earlier, not every user knows how to patch, but in ubuntu for example it is fairly easy (and encouraged by the official forums/wikis) for those users to add additional repositories using synaptic or adept or editing /etc/apt/sources.list. I mean, there were huge objections against FUSE too, remember? But Miklos built a steady and growing userbase. Maybe that is something to realize, Hans, we don't need kernel inclusion to have a growing userbase. (or atleast a steady one) A side note: the only time we had not reiserfs-list and lkml collide (that much) was when Andrew Morton was commenting and when Cristoph made a list of "things to phix" - that cost people some nerve but it nevertheles was more productive than the usual flamewars. -- Best regards, Maciej
Re: reiser4 can now bear with filled fs, looks stable to me...
Maciej Sołtysiak wrote: Hello David, - it is more expensive to: a) succeed at kernel inclusion b) argue c) waste time You must be new here... Options B and C are all that ever seems to happen when reiserfs-list and lkml collide. Is option A possible? The speed of a nonworking program is irrelevant. The cost-effectiveness of an impossible solution is irrelevant.
Re: reiser4 can now bear with filled fs, looks stable to me...
Hello David, Monday, July 31, 2006, 1:30:47 AM, you wrote: > Amen. I do not want to see Reiser4 not succeed because of politics, and > it really looks like the only way to win the political war is not to > play. The technical stuff is really the last way in, but neither side > has said anything technical in awhile. The most technical things that > have happened lately is Hans pointing to benchmarks and LKML pointing to > ext3 "plugins". So let's do the math (cost-wise, time-wise) - it is cheaper to develop: a) quality patches b) distro rpms c) repositories with patched sources and binary kernels for debian/ubuntu d) other - it is more expensive to: a) succeed at kernel inclusion b) argue c) waste time -- Best regards, Maciej
Re: reiser4 can now bear with filled fs, looks stable to me...
On Mon, 2006-07-31 at 03:08 -0500, David Masover wrote: > Hans Reiser wrote: > > It might even be socially effective to shut down reiserfs-list until > > inclusion occurs. > > Maybe. It will be an inconvenience for me, if we have to. I'm not even > on LKML, and I'd rather not be -- even this list can get noisy at times... > > But I will go with it if it's what works best. I agree with David, for whatever that is worth (I'm just a user of ReiserFS, not a developer). --Dan
Re: reiser4 can now bear with filled fs, looks stable to me...
Hans Reiser wrote: I think that most of our problem is that we are too socially insulated from lkml. They are a herd, and decide things based on what thoughts echo most loudly. To be fair, it's not the whole lkml you have to convince, just the few people directly responsible for filesystems and 2.6 maintenance. But then, they probably do consider what the herd is saying... It might even be socially effective to shut down reiserfs-list until inclusion occurs. Maybe. It will be an inconvenience for me, if we have to. I'm not even on LKML, and I'd rather not be -- even this list can get noisy at times... But I will go with it if it's what works best.
Re: reiser4 can now bear with filled fs, looks stable to me...
I think that most of our problem is that we are too socially insulated from lkml. They are a herd, and decide things based on what thoughts echo most loudly. That none of the shy developers working for me actively post on lkml hurts us quite a bit. It might even be socially effective to shut down reiserfs-list until inclusion occurs. Hans
Re: reiser4 can now bear with filled fs, looks stable to me...
Christian Trefzer wrote on 07/30/06 15:38: > Hi, > > I booted 2.6.18-rc2-mm1 today and later filled up my /opt partition by > accident, and guess what, reiser4 did not screw up : D Lucky you. I tried -rc2-mm1 today, and out of habit, the first thing I do is an fsck on my reiser4 partitions. And that resulted in a crash :-( I am now back to -rc1-mm1, which was the last one that's stable for me. -Joe
Re: reiser4 can now bear with filled fs, looks stable to me...
Christian Trefzer wrote: Hi, I booted 2.6.18-rc2-mm1 today and later filled up my /opt partition by accident, and guess what, reiser4 did not screw up : D Hmm, I'm curious, though... How does it react to a few billion files? Sorry, I can't test this, but I will be testing MythTV, if not now, then in a few weeks. Congratulations and thanks to the namesys developers! Hans, I can somewhat understand how you feel about your situation. Don't let frustration get in your way, your work is simply too great. You're an [...] screwing over society ; ) Sometimes you just have to swallow your pride instead of wasting your time by yelling at the rest of the world, and if "humble work" does not lead to success, there won't be any other way, I fear. Amen. I do not want to see Reiser4 not succeed because of politics, and it really looks like the only way to win the political war is not to play. The technical stuff is really the last way in, but neither side has said anything technical in awhile. The most technical things that have happened lately is Hans pointing to benchmarks and LKML pointing to ext3 "plugins". I suspect part of this is simply the word "plugin" coming around to bite us in the ass, but whatever. We're all tired of this fight. IMHO it would be best to deliver "quality patches" against all kinds of sources (distro kernels, vanilla -rcs maybe, etc.) Well, we have the patches against vanilla, which seem to work well with at least a few other patches I've tried. and the entire patched source tarball as well, for people to download and build. Next step would be to provide binary packages, and repos for people to add to their package manager's source list. Until distros pick up their respective patch, this is as far as support can go, I guess. That would actually be pretty good, for anyone making the conscious decision to use a filesystem. Still need official distro support to get the people who don't (think they) care. So, what do you all say? Sounds good. I don't have any idea of the work required, either...
reiser4 can now bear with filled fs, looks stable to me...
Hi, I booted 2.6.18-rc2-mm1 today and later filled up my /opt partition by accident, and guess what, reiser4 did not screw up : D I already planned on forcibly filling up something less depended upon, like the portage tree, but studies kept me from playing and the scheduled java vm update took care of it... Congratulations and thanks to the namesys developers! Hans, I can somewhat understand how you feel about your situation. Don't let frustration get in your way, your work is simply too great. You're an emotional kind of guy - don't get me wrong, so am I and at least once a day I want to run off and knock out some lying politician scum for screwing over society ; ) Sometimes you just have to swallow your pride instead of wasting your time by yelling at the rest of the world, and if "humble work" does not lead to success, there won't be any other way, I fear. IMHO it would be best to deliver "quality patches" against all kinds of sources (distro kernels, vanilla -rcs maybe, etc.) and the entire patched source tarball as well, for people to download and build. Next step would be to provide binary packages, and repos for people to add to their package manager's source list. Until distros pick up their respective patch, this is as far as support can go, I guess. This is not about forking, it's more about providing the service we'd want kernel.org to provide for us and which will possibly happen some time, in some way. If they won't push you, you have to push by yourself, sad but true. This is also _not_ meant as the start of yet another flame war, and $deity be my witness, I won't reply on any non-technical polarizing bullshit, damnit. And this is exactly the reason why I won't cross-post this to LKML, where OT-flames span topics from ext4 over suspend2 to the 2.4-2.5 transition. Some people really do have too much time on their hands. This is about what can be done to bring reiser4 to the users, at least to those who know about differences in file systems. To anybody else, it simply won't matter anyway. So, to get to an end now, as I really need to get some sleep: where do we start? - a git tree might be very helpful in the beginning, separating, in branches, the self-contained source code from the kbuild part that may intersect with diverging modifications in different patchsets/vendor sources. - next we could adapt, in branches forking off of the vanilla kbuild branch, the kbuild-related parts to different distro kernels, maybe even old versions. Troublesome are things like changing APIs, but that can be taken care of and has been in the past. - once we get a source repo that takes into account several distro-patched kernels, we can generate patches with git against those kernel sources, build binary packages, and maybe even binary modules as separate packages for minimal installation effort. Maybe I am a bit too optimistic estimating the amount of work required for this, but seeing a pretty stable (and self-contained!) code base being torn appart to satisfy some obscure need for generalization, which might even yield _no approach towards inclusion_ nonetheless, just makes me feel sick. I personally don't care about new semantics as long as they are absolutely backwards-compatible, like test ! -d on a file that has file/.../metadata stuff still returns true for instance. But the core fs, disk layout etc. are stable AFAICS, so screw politics and get the job done ; ) New features will come with mount options only, anyway. So, what do you all say? Nighty-night, Chris -- committee: too many arguments to function pgpLBbTzNzyGg.pgp Description: PGP signature