If you took the Mandrake installer. Mandrakes up-to-dateness (stable debian isn't current enough), and mandrakes cool graphical tools and combine them with debians apt-get and overall os quality,
The problem is one of the big reasons Debian's overall OS quality is so high because the packages are slightly older. There's more time to make sure everything works as it should.
The graphical tools and installer would be nice for some people, as long as the ncurses installer is still a choice.
I got my first free car ~3 years ago, I put maybe $1200 into semi-normal repairs (oil changes, brake pads, etc) and it's been running near perfect the whole time. I still drive it every day and it's got 145,000 miles on it.
Friend of mine bought a brand new G4 tower, 2 days later the hard drive died. Sure, it was replaced for free but in the end they sell nearly all the same hardware as IBM or Dell. IDE drives, PC133 SDRAM, nVidia video card, etc.
1) RPM is already the standard package format for the LSB 2) Apt is a front end to the package manager, whatever you come up with will probably be usable with apt with a little tweaking.
Doesn't anyone think the FreeBSD team should get their ACPI and IRQ sharing stuff worked out? Sure MS dictating hardware standards isn't good, but from a purely technical standpoint the problem here is FreeBSD.
thats complete nonsense. the behaviour you're describing is what any multitasking kernel does.
Not entirely, without this patch any kernel code path executes until it returns or manually calls schedule() and if you have a UP box all other processes don't get to run. But, my example of a hard disk read may have been poorly chosen.
the preemptive kernel patch, which ensures that when a task becomes runnable (for example, due to a device interrupt that tells the CPU that a condition the task was waiting for is met), it can start running ASAP, rather than waiting till the next regular re-scheduling point.
The preempt patch allows processes stuck in kernel paths to be put to sleep so others can run, I don't believe it gives those processes any priority boost because they were in a kernel path but I could be wrong about that.
It sounds like you're describing a real-time scheduler more than a preemptive kernel.
A preemptive kernel is allowed to be stopped for another higher priority task, in the default kernel only userspace apps can be preempted. What this means is if an app is reading from the disk (the syscall for block I/O is run in kernel mode on the app's behalf) and the disk read is taking a long time (many milliseconds) that kernel path can be paused to allow other processes to run while the disk finishes it's read.
If you read the interview you would have seen: "Linus said at ALS this year he was interested in the preempt-kernel patch. That doesn't mean anything to me until we are in, though, but it is a good sign."
And right now Linus hasn't let this and several other patches into 2.5 officially becaues he's focusing on the bio changes and it's much harder to debug if you have multiple subsystem changes going on at once. And Linus also has shown interest in Ingo's new O(1) scheduler, which the preempt patches have only recently become compatible with.
Obviously, you want someone that knows the kernel really well and can maintain every part of it.
That person doesn't exist, not even Linus knows every part of the kernel inside and out.
You have to trust the maintainers of their parts of the kernel because as good as Linus, Marcelo, Alan, etc are they can't know all the gotchas, etc of all the drivers and different kernel subsystems.
Aren't you taking a good developer (who can maintain every part of the kernel) away from the newer versions of the kernel?
They don't have to do it if they don't want to or don't have the time. But with Alan's recent want to not maintain 2.4.x so he can work on other things seems to say how much time is really required for the maintenance of a kernel tree.
There are only so many developers, what happens if you run out?
I highly doubt there will ever be that many currently maintained kernel versions.
This was brought up on the LKML already and doesn't seem like a bad idea but would take another major overhaul in the kernel to make it work, something like this may happen in 2.5 but I wouldn't bet on it.
Some decisions lately have been questionable, but Rik and Andrea are both just trying to get a VM in 2.4 that works so 2.5 can be opened, which would make a lot of people happy.
Read it again, he said it wouldn't compile because of NTFS support and if he's enabled NTFS support on his NFS server who knows what else is there that shouldn't be?
Yes XFS should run fine on top of LVM. If you plan to do so please keep in mind that the current XFS cvs tree (and also the XFS 1.0 previews) already contains the lvm beta6 code and some tweaks for XFS - currently it is recommended to stay with this version instead of the current lvm version (beta7 at the moment) because there are some logistical problems around that version. Martin K. Petersen is keeping an eye on the lvm in the XFS tree as soon as there is a recommended new version of it i think. Keep one thing in mind with XFS on lvm: mounting snapshots of lvs containing XFS filesystem does not work due to the journaling nature of the filesystem (but a fix for this is on the TODO list).
Q: Does XFS run with the linux software RAID md driver?
Yes - the current XFS tree and the latest released previews contain fixes which should allow you to run XFS on top of any md RAID level.
And you can also use XFS safely on NFS exports, something reiserfs was still fighting with, and required a seperate patch to work properly with last I checked. --
I've had no problems running XFS on my main x86 box and my Alpha, although ACLs don't work on Alpha yet.
I think reiserfs is still too young, they've already changed the on-disk format between 3.5.X and 3.6.X and now they plan on redoing the tail packing, I'm all for rapid development but I'd rather keep my data on something that atleast has stablized blueprints. --
You need more memory, 128M is the minimum required by MS. Also each user logged in gets so much memory allocated for the desktop and for each app they run, allocate an additional 10M minimum for each user connecting if they're only running 1 app at a time, add more if they're running more than one app at a time. I would try to give each concurrent user ~30M, more if possible, and don't forget about how much memory the OS itself needs. --
I was bored and tried your "test" on two of my boxes, an Alpha 4/266 and a Celeron 466 both running Debian woody, both have gcc 2.95.3 20010125 (prerelease).
The Intel box got 10=9 and the Alpha got 10=10. --
I believe the patches at the Linux VPN Masq page are supposed to work with PPTP, I know I've used it to establish an IPSec VPN with the client behind a NAT box.
Slashdot Mirror
You don't need to update the kernel, infact I'm pretty sure the default woody kernel is still in the 2.2s.
The problem is one of the big reasons Debian's overall OS quality is so high because the packages are slightly older. There's more time to make sure everything works as it should.
The graphical tools and installer would be nice for some people, as long as the ncurses installer is still a choice.
Price isn't everything.
I got my first free car ~3 years ago, I put maybe $1200 into semi-normal repairs (oil changes, brake pads, etc) and it's been running near perfect the whole time. I still drive it every day and it's got 145,000 miles on it.
Friend of mine bought a brand new G4 tower, 2 days later the hard drive died. Sure, it was replaced for free but in the end they sell nearly all the same hardware as IBM or Dell. IDE drives, PC133 SDRAM, nVidia video card, etc.
1) RPM is already the standard package format for the LSB
2) Apt is a front end to the package manager, whatever you come up with will probably be usable with apt with a little tweaking.
I'm curious how you think a (currently)free wireless Internet connection is going to make music piracy and child pr0n any more popular?
Just because I can connect to the Internet from the Point doesn't mean I immediately go download unreleased CDs or naked 8 year olds.
Doesn't anyone think the FreeBSD team should get their ACPI and IRQ sharing stuff worked out? Sure MS dictating hardware standards isn't good, but from a purely technical standpoint the problem here is FreeBSD.
Not entirely, without this patch any kernel code path executes until it returns or manually calls schedule() and if you have a UP box all other processes don't get to run. But, my example of a hard disk read may have been poorly chosen.
the preemptive kernel patch, which ensures that when a task becomes runnable (for example, due to a device interrupt that tells the CPU that a condition the task was waiting for is met), it can start running ASAP, rather than waiting till the next regular re-scheduling point.
The preempt patch allows processes stuck in kernel paths to be put to sleep so others can run, I don't believe it gives those processes any priority boost because they were in a kernel path but I could be wrong about that.
It sounds like you're describing a real-time scheduler more than a preemptive kernel.
A preemptive kernel is allowed to be stopped for another higher priority task, in the default kernel only userspace apps can be preempted. What this means is if an app is reading from the disk (the syscall for block I/O is run in kernel mode on the app's behalf) and the disk read is taking a long time (many milliseconds) that kernel path can be paused to allow other processes to run while the disk finishes it's read.
And right now Linus hasn't let this and several other patches into 2.5 officially becaues he's focusing on the bio changes and it's much harder to debug if you have multiple subsystem changes going on at once. And Linus also has shown interest in Ingo's new O(1) scheduler, which the preempt patches have only recently become compatible with.
Obviously, you want someone that knows the kernel really well and can maintain every part of it.
That person doesn't exist, not even Linus knows every part of the kernel inside and out.
You have to trust the maintainers of their parts of the kernel because as good as Linus, Marcelo, Alan, etc are they can't know all the gotchas, etc of all the drivers and different kernel subsystems.
Aren't you taking a good developer (who can maintain every part of the kernel) away from the newer versions of the kernel?
They don't have to do it if they don't want to or don't have the time. But with Alan's recent want to not maintain 2.4.x so he can work on other things seems to say how much time is really required for the maintenance of a kernel tree.
There are only so many developers, what happens if you run out?
I highly doubt there will ever be that many currently maintained kernel versions.
Love doesn't maintain a complete seperate kernel tree, just a patch that applies to the main Linus tree.
Why?
We already have FSes built from the ground up in the form of reiserfs, XFS, JFS, etc. What would the point be in doing another?
This was brought up on the LKML already and doesn't seem like a bad idea but would take another major overhaul in the kernel to make it work, something like this may happen in 2.5 but I wouldn't bet on it.
Some decisions lately have been questionable, but Rik and Andrea are both just trying to get a VM in 2.4 that works so 2.5 can be opened, which would make a lot of people happy.
You mean like Apple did with OS X?
Read it again, he said it wouldn't compile because of NTFS support and if he's enabled NTFS support on his NFS server who knows what else is there that shouldn't be?
Same here with ATT@Home in Pennsylvania.
From the XFS FAQ:
And you can also use XFS safely on NFS exports, something reiserfs was still fighting with, and required a seperate patch to work properly with last I checked.
--
I've had no problems running XFS on my main x86 box and my Alpha, although ACLs don't work on Alpha yet.
I think reiserfs is still too young, they've already changed the on-disk format between 3.5.X and 3.6.X and now they plan on redoing the tail packing, I'm all for rapid development but I'd rather keep my data on something that atleast has stablized blueprints.
--
I believe that would be called IPv6.
--
You need more memory, 128M is the minimum required by MS. Also each user logged in gets so much memory allocated for the desktop and for each app they run, allocate an additional 10M minimum for each user connecting if they're only running 1 app at a time, add more if they're running more than one app at a time. I would try to give each concurrent user ~30M, more if possible, and don't forget about how much memory the OS itself needs.
--
I second the comment about Debian on Alpha, I've been running testing on my Noritake for a while now and have had virtually no problems.
The Debian-Alpha mailing list is especially helpfull too.
--
the mount option 'conv' works for 3.5.x -> 3.6.x (or whatever the version difference between the linux 2.2 and 2.4 reiserfs patches are)
I have to agree on the ext3 thing though, I use it on my Alpha and my Sparc because reiserfs isn't (or atleast wasn't) working on either of them.
--
I was bored and tried your "test" on two of my boxes, an Alpha 4/266 and a Celeron 466 both running Debian woody, both have gcc 2.95.3 20010125 (prerelease).
The Intel box got 10=9 and the Alpha got 10=10.
--
Don't know if it works with iptables or not.
--
Who cares what "the standard" turns out to be? You can run reiserfs all you like either way.
--