OpenBSD's sparc64 port is 64-bit but the last time I tried it there was still a lot of work to do. It worked for the most part (it was just a pf box) but a lot of little problems caused me to drop it in favor of Debian/sparc64 again.
And it was a PITA to install since there's no tftp bootable images like there are for Linux.
Re:Besides Debian, What distros have 2.6.x ?
on
Kernel 2.6.1 Released
·
· Score: 2, Insightful
I've been using it since test9 and havn't had any major issues.
And on top of that, if noone uses it until 2.6.15 how will any of the bugs get found? The kernel developers have been using it since 2.5.x so they've probably found all the major bugs dealing with the hardware they all use, the testing base has to be widened to find the odd bugs and that's why 2.6.0 was released when it was.
The probject hasn't left off anywhere, the core team is disbanding but the bulk of the developers are still around. Basically management has given up full control to the more active developers.
From what I've seen it appears they were slowing development more than steering it anyway, do you have any idea how many patches the Debian X package maintainers had to maintain because the X team was so slow at accepting patches?
Network drivers and the TCP/IP stack run in kernel-mode sure, but the fact that your boxes hung has nothing to do with the x86 architecture, you have either a buggy NIC driver or a buggy TCP/IP stack (well or IPX or DECNet or whatever) causing some problem.
I would probably blame your mentioned crash on ZoneAlarm, it probably installs some network filter driver that was coded poorly.
So just don't use UserLinux, who cares what they include and don't include? There's plenty of other, commercially supported distros out there.
I personally don't like QT or KDE so I couldn't care less if every distro stopped shipping them, but I'm not going to cry if SuSe starts excluding Gnome either.
Some people probably did, but you can't control what everyone says. 2.4.x was better because it thinned out use of the BKL but it still wasn't very granular and the process scheduler was only so-so. Now we have the O(1) scheduler to handle practically any number of concurrent processes easily and the locking is granular enough that it should be possible to realistically run Linux on 16 and 32-way SMP systems now.
Well following me own advice, Gentoo as well as Redhat 9 are incompatible with the new module format of 2.6!
No they're not, you just need to install module-init-tools. It sits along-side modutils just fine so you can boot back into 2.4.x if you need to without any breakage.
If you're letting the OS do the caching you could get an IA32 system that handles >4G memory and the performance would probably be close, I'm not sure how much of a performance hit PAE in the kernel has but the price difference might make it worthwhile. And since you'd be relying on the normal Linux page cache the applications don't have to be 64-bit aware to have all that memory used for their caching.
>4G physical memory isn't always the selling point, you can cram more than 4G memory into many 32-bit systems right now. The big thing is the >4G VM space of the 64-bit architecture which doesn't always map to physical memory, things like mmap()'d files, shared libraries, etc take up VM space too, so an app can need more VM space without needing more physical memory.
Your problem was hardware related and I doubt their 'findings' would have been any different unless they were testing things like Oracle that would actually use that extra memory.
I read a while ago that it comes with both versions of alot of applications because right now it's more of a development platform than anything else.
And frankly with how well Opteron handles 32-bit apps there's no reason to ship 64-bit versions of everything, a 32-bit userland with a 64-bit kernel and the option to run 64-bit userland apps as necessary is more than enough and infact that's how a number of Linux builds work, sparc64 comes to mind quickly since I have two of them.
The big problem is shared libraries, it's not a good idea (or not possible, I'm not 100% sure) to mix them so to run 32-bit IE on a 64-bit system you need a 32-bit copy of every library it depends on. And if you want to run a 64-bit version along side it you need both versions of all the libraries too. This is the biggest problem Debian is having right now, getting bi-architecture support to work cleanly.
Re:No such thing as a Linux beginner?
on
Linux Power Tools
·
· Score: 1
and when the screen displays 4 penguins instead of 1 I know that it's a screen resolution problem, not a "it doesn't work" problem.
Depends. When the console is configured to use a framebuffer a penguin for each CPU is printed above the boot messages, so if you have 4 CPUs you'd have 4 penguins.
dd would have the same problems as dump, so that leaves tar, cpio or a 'bigger' offering like Arkeia.
The page cache is necessary, do you know how slow Linux would be if it had to make sure every on disk file was in sync with pages in memory?
The real 'problem' is there's nothing like DMAPI for generic block devices to allow things like dump to work like they should. Unless you want to use LVM snapshots.
sync still exists, but you can't be guaranteed that nothing will get modified in memory while the dump is in progress unless you unmount or remount the filesystem read-only. Or use something like an LVM snapshot like was mentioned by another poster.
In this case journaling is only one of the main features of the filesystem. XFS is much faster than ext3, supports logging to a seperate device to speed it up even more, nicely supports huge filesystems and file sizes and has much nicer userland tools.
Personally, anyone looking for a data-redundancy fix should use ReiserFS (which we have had for a looong time), JFS or XFS.
I would definatley not recommend reiserfs if you care about data. I've had atleast 2 occiasions where it lost data for no good reason. I would rather use ext2 than reiserfs any more, but when available I use XFS.
dump is not recommended with ext2 or ext3 because it opens the block device directly which bypasses the page cache and can give you corrupt data if there are dirty pages that havn't been flushed to disk.
I'm not sure if xfsdump is any smarter about it because of the DMAPI stuff available, but I'd be carefull.
This is a local exploit, it can't be used until you have a shell. Debian had the misfortune of having a developer's password stolen and used to get a shell, other distros would have to have similar problems with either passwords or network accessable services.
This isn't a special situation, everyone should be checking the integrity of their servers periodically anyway.
Looks can be decieving. Just because it's text doesn't mean it's hard.
And as was mentioned many times before, it's text because they need to support 11 architectures, some of which support installing without any video hardware, so a text installer that can be run over a serial cable is a must. The text installer is the lowest common denominator and that's why it's being done first, the install system is seperated well enough that other front-ends can be written in whatever toolkit you want and a GTK one is already being worked on.
PPC is easy, it's almost the same as x86 hardware wise. But what about sparc64? Some sparc64 boxes don't even have PCI busses, do you think MDK has any idea how to detect hardware on SBus?
The GNU/ part actually makes sense in Debian though because there are things like the Debian GNU/FreeBSD project which is working to get the Debian and GNU userland working with the FreeBSD kernel, so it's a major difference here.
x86-64 on workstations is a lot more work because you have to have 32-bit compatibility because you're more likely to want to run an app that can't be recompiled for the 64-bit target. On the server side they just say "we don't support 32-bit binaries" and don't worry about it.
Slashdot Mirror
OpenBSD's sparc64 port is 64-bit but the last time I tried it there was still a lot of work to do. It worked for the most part (it was just a pf box) but a lot of little problems caused me to drop it in favor of Debian/sparc64 again.
And it was a PITA to install since there's no tftp bootable images like there are for Linux.
I've been using it since test9 and havn't had any major issues.
And on top of that, if noone uses it until 2.6.15 how will any of the bugs get found? The kernel developers have been using it since 2.5.x so they've probably found all the major bugs dealing with the hardware they all use, the testing base has to be widened to find the odd bugs and that's why 2.6.0 was released when it was.
The probject hasn't left off anywhere, the core team is disbanding but the bulk of the developers are still around. Basically management has given up full control to the more active developers.
From what I've seen it appears they were slowing development more than steering it anyway, do you have any idea how many patches the Debian X package maintainers had to maintain because the X team was so slow at accepting patches?
ActiveX runs in userland though, so unless it interfaces with something buggy in the kernel it can't crash the kernel.
Network drivers and the TCP/IP stack run in kernel-mode sure, but the fact that your boxes hung has nothing to do with the x86 architecture, you have either a buggy NIC driver or a buggy TCP/IP stack (well or IPX or DECNet or whatever) causing some problem.
I would probably blame your mentioned crash on ZoneAlarm, it probably installs some network filter driver that was coded poorly.
If we want "no choice", we can use Windows.
So just don't use UserLinux, who cares what they include and don't include? There's plenty of other, commercially supported distros out there.
I personally don't like QT or KDE so I couldn't care less if every distro stopped shipping them, but I'm not going to cry if SuSe starts excluding Gnome either.
Some people probably did, but you can't control what everyone says. 2.4.x was better because it thinned out use of the BKL but it still wasn't very granular and the process scheduler was only so-so. Now we have the O(1) scheduler to handle practically any number of concurrent processes easily and the locking is granular enough that it should be possible to realistically run Linux on 16 and 32-way SMP systems now.
Well following me own advice, Gentoo as well as Redhat 9 are incompatible with the new module format of 2.6!
No they're not, you just need to install module-init-tools. It sits along-side modutils just fine so you can boot back into 2.4.x if you need to without any breakage.
If you're letting the OS do the caching you could get an IA32 system that handles >4G memory and the performance would probably be close, I'm not sure how much of a performance hit PAE in the kernel has but the price difference might make it worthwhile. And since you'd be relying on the normal Linux page cache the applications don't have to be 64-bit aware to have all that memory used for their caching.
>4G physical memory isn't always the selling point, you can cram more than 4G memory into many 32-bit systems right now. The big thing is the >4G VM space of the 64-bit architecture which doesn't always map to physical memory, things like mmap()'d files, shared libraries, etc take up VM space too, so an app can need more VM space without needing more physical memory.
Your problem was hardware related and I doubt their 'findings' would have been any different unless they were testing things like Oracle that would actually use that extra memory.
I read a while ago that it comes with both versions of alot of applications because right now it's more of a development platform than anything else.
And frankly with how well Opteron handles 32-bit apps there's no reason to ship 64-bit versions of everything, a 32-bit userland with a 64-bit kernel and the option to run 64-bit userland apps as necessary is more than enough and infact that's how a number of Linux builds work, sparc64 comes to mind quickly since I have two of them.
The big problem is shared libraries, it's not a good idea (or not possible, I'm not 100% sure) to mix them so to run 32-bit IE on a 64-bit system you need a 32-bit copy of every library it depends on. And if you want to run a 64-bit version along side it you need both versions of all the libraries too. This is the biggest problem Debian is having right now, getting bi-architecture support to work cleanly.
and when the screen displays 4 penguins instead of 1 I know that it's a screen resolution problem, not a "it doesn't work" problem.
Depends. When the console is configured to use a framebuffer a penguin for each CPU is printed above the boot messages, so if you have 4 CPUs you'd have 4 penguins.
dd would have the same problems as dump, so that leaves tar, cpio or a 'bigger' offering like Arkeia.
The page cache is necessary, do you know how slow Linux would be if it had to make sure every on disk file was in sync with pages in memory?
The real 'problem' is there's nothing like DMAPI for generic block devices to allow things like dump to work like they should. Unless you want to use LVM snapshots.
sync still exists, but you can't be guaranteed that nothing will get modified in memory while the dump is in progress unless you unmount or remount the filesystem read-only. Or use something like an LVM snapshot like was mentioned by another poster.
In this case journaling is only one of the main features of the filesystem. XFS is much faster than ext3, supports logging to a seperate device to speed it up even more, nicely supports huge filesystems and file sizes and has much nicer userland tools.
I hope you verify those backups because Linus' hate for dump has a reason behind it.
Personally, anyone looking for a data-redundancy fix should use ReiserFS (which we have had for a looong time), JFS or XFS.
I would definatley not recommend reiserfs if you care about data. I've had atleast 2 occiasions where it lost data for no good reason. I would rather use ext2 than reiserfs any more, but when available I use XFS.
dump is not recommended with ext2 or ext3 because it opens the block device directly which bypasses the page cache and can give you corrupt data if there are dirty pages that havn't been flushed to disk.
I'm not sure if xfsdump is any smarter about it because of the DMAPI stuff available, but I'd be carefull.
This is a local exploit, it can't be used until you have a shell. Debian had the misfortune of having a developer's password stolen and used to get a shell, other distros would have to have similar problems with either passwords or network accessable services.
This isn't a special situation, everyone should be checking the integrity of their servers periodically anyway.
Looks can be decieving. Just because it's text doesn't mean it's hard.
And as was mentioned many times before, it's text because they need to support 11 architectures, some of which support installing without any video hardware, so a text installer that can be run over a serial cable is a must. The text installer is the lowest common denominator and that's why it's being done first, the install system is seperated well enough that other front-ends can be written in whatever toolkit you want and a GTK one is already being worked on.
PPC is easy, it's almost the same as x86 hardware wise. But what about sparc64? Some sparc64 boxes don't even have PCI busses, do you think MDK has any idea how to detect hardware on SBus?
The GNU/ part actually makes sense in Debian though because there are things like the Debian GNU/FreeBSD project which is working to get the Debian and GNU userland working with the FreeBSD kernel, so it's a major difference here.
x86-64 on workstations is a lot more work because you have to have 32-bit compatibility because you're more likely to want to run an app that can't be recompiled for the 64-bit target. On the server side they just say "we don't support 32-bit binaries" and don't worry about it.
You mean like systrace?