Am I the only one who wants a laptop with fewer features, not more?
How about no dvd, no floppy, no firewire, no parallel port, no pcmcia, NO M$ WINDOWS!, no external svga socket, no built in modem, no built in ethernet, no sound, no irda, no 1e+34 key keyboard, no ps/2 mouse port, no ps/2 keyboard port, no kitchen sink.
I think that's a bit too much of an extreme. DVD is overkill but can be nice if you fly alot. At least one PCMCIA slot is a must tho, if there's no builtin ethernet. Even if there is it's nice for other things like 802.11b[*]. Or you can get a USB adapter or firewire adapter and expand any way you like. USB ethernet is OK for small things, but if you have a 'decent' size HD you'll probably want something relatively fast.
IMHO, the 'best' laptops are the rather old ones now. I've got an old AST Ascentia J right here with an upgraded HD. More battery life would be nice, a p100 & 40mb of RAM is enough for most things.
[*] - There are USB 802.11b adapters, but none of 'em work in Linux yet.
Not quite. VMWare is x86-only I believe. But there is Mac-On-Linux which will work with OS 9.x (but not OS X) and you can run a PC emulator in side of that if you feel the need for a Windows-only program.
Not personally, but it does work. There's even unofficial kernel debs floating around with support for it, and yaboot just added support for booting off of XFS partitions.
In general terms, it like comparing Debian/x86 to RedHat. YellowDog is still somewhat RedHat'ish last I knew.
But more importantly, Debian/PPC is doing great. I can't think of any glaring PPC-specific bugs in either Woody or Sid right now.
Re:Belkin makes one...
on
USB Switches?
·
· Score: 1
I don't really think it's possible to 'switch' USB in the same sense that networking does, directly. But you can always grab another USB PCI card, if you've got a slot.
The univeristy of arizona (UofA) has been doing this for a few years (originally w/ java 1.0 I think). The first 2 required classes are all done in java. I don't think this was wholly bad. Mainly because first we didn't have to (and didn't use at all really) the fact that Java is ment to be OO. It was introduced and used near the end of the second class for projects, but not empisized. The other strong point (which the Prof disliked actually, since he was very much an OO person) is that Java has similar syntax to C and C++. The other smart thing to UofA did was realize that java is NOT useful for lots of things too. The recommended next classes were 'Introduction to UNIX' and 'Systems Programming' which was taught in mips32 asm with SPIM and then C. This has changed slightly to emphisize C more as students still had problems doing C well.
All in all, I don't think Java is a bad langauge to use for an introduction, but it should be followed up quickly by C or C++.
Why do I say that? The glibc team did their best to maintain compatiblity from glibc 2.0, to 2.1, to 2.2. The only time this isn't true, and isn't a bug, is if the application used some glibc internal function. This is why things like star office (5.0 or 5.1, I forget) broke from 2.0 to 2.1. It's also probably why Oracle broke. But, if it's not the case, file a bug report and maybe it can be fixed for glibc 2.2.2.
Well, yes people objected to sourceforge fwd'ings to the -dev list. Hence Dave Wolfe (the guy running all the lists) is creating a list for them. So yes, I do think you're a bit too cynical Who have you been reporting these bugs to? The one you're referring to is rather well known (Paul knows about it, Cort knows about it, I think everyone knows about it.) The problem is finding time to yank yet another hw bug fix out of darwin. What machine do you have anyways. And dare I ask what "2.1.24" kernel it was? That tree took ages to finally die.
The only problem here is that Cort (the maintainer for PPC) has been sending in patches since the late 2.3 days. Hell, 2.3.49ish or so was actually up to date. There wasn't too much work being done on PPC-specific things (because the main kernel was too buggy and liked to eat FS'). But as other people have said, if you're machine isn't x86, you shouldn't be using the "main" tree anyways. It's not Linus' fault or the maintainers fault. It just happens. It's also certainly not a "War".
> It's pretty hard to keep up with nowadays. It is apparently getting worse.
Actually, as of 2.4.2preN, the difference is much smaller than it used to be (>500kB). It's still missing critical things like IDE updates, but it's not as bad as before.
What SMP box do you have? The dual G4s work rather well, and the daystar boards are still being fixed up (they almost work rather stabily). Finally, Linux (2.2.18 and 2.4.N, from the right tree of course) can read/write HFS rather well. I wouldn't use my main volume, but i've had a 32mb partition on a few machines, and diskcheck (the apple util, I think thats the name but I'm not sure). hasn't found any errors.
As someone who actually works on the PPC kernel, I do admit that there are bugs, but the other side of the coin is that hardly anyone reports these things. The developers only have a finite number of machines, and can only test what they have.
But anyways, frambuffers are working well (with an occasional problem on the wierder ATIs, or some of the undocumented apple controllers.) Serial was broken once upon a time, but that's been fixed for ages (and even made it into Linus' tree in 2.4.2pre2). I assume you're referring to "standard" IDE cards which work in 2.4. Patches do indeed get ignored, but again there's more people trying to keep track of things now.
As for the rewrites you mention, I know some of the recent ones have been so that new machines can be used and maintained sanely.
It does depend a lot on what you're doing. If you
want a nice card for driving big monitors, and getting work done, along with the occasional 3D game, I'd say go with a Matrox G400. They're really nice, well supported, and for all the features that work now and will work someday (DVD), they're a good deal. I'd stay away from the 450s for now, just because they're still rather new, and from the reviews I've seen they only really beat the 400 in price. I've had a Millennium 1, 2, G100, G200 and now a G400 and all
have worked wonderfully under linux.
Actually, no. IIRC, there are two styles for rc files. BSDish (/etc/rc.init or so, and it does everything) and SystemVish, which at least RH and Debian are. Both store their scripts in/etc/init.d (RH7 moved 'em there,/etc/rc.d/init.d in older versions.) Looking at the portmap script from woody and RH6.2, they both have the same layout (check if it exists, then see if it's start/stop/reload/restart). So yes, the rc scripts are almost identical. Different commands to do things, yes, but virtually the same format. If you can understand one, you can understand both. As for slack, I can't say.
While the.debs have a more human-readable dependancy, this isn't as big of a win as you might think. Very few people resolve missing deps in debian by hand (I never do), apt/dpkg figure it out. Personally, I think it'd rock if dh_shlibs made more rpm-ish deps (ie symbol@GLIBC_2.2, etc) since this would allow for a lot more accurate dependancies to be made.
This is sort of possible anyways. At least the first part. If a package has a.spec file in it, rpm -tb something.tar.gz will go, build and spit out/usr/src/redhat/RPMS/$ARCH/something-somever.$ARCH.rpm
This argument works just as well with debs as RPMs. The only problem being a lot more packages provide a specfile so you can rpm -ta foo.tar.gz than provide the debian dir. And while official rpms do lag behind the release, this happens with debian as well. And for those packages which don't have a specfile, it's _usually_ trivial to change the specfile (yes, you do have to dl a bit more) for the current version. Back when I had time I managed to keep a RH5.1 (originally) system up to date until I found something better to do.
Debian just lets you be lazy and not have to compile things to stay up to date.
As for the rc files, They look to be about the same as debians anyways.
Well, about the first comment, yes if you don't try and upgrade libraries and basically ignore your dependancies errors show up. You can quite easily do this on a debian system too. If the main libraries the program wants are too old, and your system doesn't have them,.debs don't help you either. It's either upgrading from 5.1 to 6.2 or whatever. Kinda like apt-get dist-upgrade, but with a bit more hassle. But when you actually listen to and use the dependancy info,.rpm is actually better than.deb
If you have access to both kinds of systems (RH6.2ish or newer and debian) do a list of dependancies on some packages. Debian will list libc6, and other things dh_shlibs or so picks up. rpm 3.0.4 (3.0.0?) will get down to all the nitty details. (Check out the yup program, it's quite good at checking all the funky deps).
Yes, but how does it compare to Blackdowns 1.3 JDK? Remember, Sun's "Linux port", at least the first round of it anyways, was re-releasing Blackdowns work, including their README file.
The Blackdown 1.3 JDK should be fine on RH7, as well as IBMs JDK, which seems much faster in the few tests I've done. And, the Blackdown JDK anyways has a -target flag, which sounds like it would compile for say, JDK 1.1.
This was one of the things we noticed when we were pulling a non profit organization (The Open Source Education Foundation). after some contemplation (and other ugly incidents) we came up with the idea of the K12 Student Pad a device that we are starting to develop. The way we see it, it should be about the size of a clip board and about 2-2.5 inchs thick, full color and run a very customized version of linux. It would interface with a new type of desk for in class use and be able to charge and network thru that desk. The other objectives we have are: Shock resistent to 10+ G's, capable of being run over by a Kenworth tractor trailor rig, water resistance to 3 meters, and be able to play 320x240 mpeg movies.
A friend of mine pointed this out this morning. It's RedHat 6.x with s/RedHat/Gentus/g and Andre Hedricks(sp?)s IDE patches applied to a 2.2.x kernel. I'm not sure about the kernel part, but those patches do add support for the UDMA/66 chipset found in the BP6. As for the 1st statement check out: http://www.gentus.com/qig-images/image002.jpg and http://www.gentus.com/qig-images/image030.jpg
Um, not really. For one it's a kernel issue, and any kernel works anywhere (BenH's, which LPPC 2k is using, working on debian, lppc, ydl and anybody elses dist for that matter) Also, the original, Well it's booting, was done long before YDL did any sort of patching.
Re:Turning up the heat on Motorola
on
Darwin on Crusoe?
·
· Score: 1
Actually, forgetting for a moment this is a totally made up rumor, it could be interesting. Everyone so far seems to assume Apple porting over OS X or whatever to x86. Why? Crusoe is not an x86 chip. If apple went to another architecture they loose all their old apps, and piss off lots of customers. But there's nothing stopping them from helping transmeta do a PPC layer. Which gives you compatibility with all your existing apps, still pretty fast CPUs (in theory) and no motorola. And, assuming Phoenix didn't have to do too much to get their BIOS happy, "porting" OpenFirmware over shouldn't be too much trouble either (just add in the crusoe specific stuffs..) Sounds good too me.
Slashdot Mirror
How about no dvd, no floppy, no firewire, no parallel port, no pcmcia, NO M$ WINDOWS!, no external svga socket, no built in modem, no built in ethernet, no sound, no irda, no 1e+34 key keyboard, no ps/2 mouse port, no ps/2 keyboard port, no kitchen sink.
I think that's a bit too much of an extreme. DVD is overkill but can be nice if you fly alot. At least one PCMCIA slot is a must tho, if there's no builtin ethernet. Even if there is it's nice for other things like 802.11b[*]. Or you can get a USB adapter or firewire adapter and expand any way you like. USB ethernet is OK for small things, but if you have a 'decent' size HD you'll probably want something relatively fast.
IMHO, the 'best' laptops are the rather old ones now. I've got an old AST Ascentia J right here with an upgraded HD. More battery life would be nice, a p100 & 40mb of RAM is enough for most things.
[*] - There are USB 802.11b adapters, but none of 'em work in Linux yet.
Not quite. VMWare is x86-only I believe. But there is Mac-On-Linux which will work with OS 9.x (but not OS X) and you can run a PC emulator in side of that if you feel the need for a Windows-only program.
Not personally, but it does work. There's even unofficial kernel debs floating around with support for it, and yaboot just added support for booting off of XFS partitions.
In general terms, it like comparing Debian/x86 to RedHat. YellowDog is still somewhat RedHat'ish last I knew.
But more importantly, Debian/PPC is doing great. I can't think of any glaring PPC-specific bugs in either Woody or Sid right now.
I don't really think it's possible to 'switch' USB in the same sense that networking does, directly. But you can always grab another USB PCI card, if you've got a slot.
The univeristy of arizona (UofA) has been doing this for a few years (originally w/ java 1.0 I think). The first 2 required classes are all done in java. I don't think this was wholly bad. Mainly because first we didn't have to (and didn't use at all really) the fact that Java is ment to be OO. It was introduced and used near the end of the second class for projects, but not empisized. The other strong point (which the Prof disliked actually, since he was very much an OO person) is that Java has similar syntax to C and C++. The other smart thing to UofA did was realize that java is NOT useful for lots of things too. The recommended next classes were 'Introduction to UNIX' and 'Systems Programming' which was taught in mips32 asm with SPIM and then C. This has changed slightly to emphisize C more as students still had problems doing C well.
All in all, I don't think Java is a bad langauge to use for an introduction, but it should be followed up quickly by C or C++.
Why do I say that? The glibc team did their best to maintain compatiblity from glibc 2.0, to 2.1, to 2.2. The only time this isn't true, and isn't a bug, is if the application used some glibc internal function. This is why things like star office (5.0 or 5.1, I forget) broke from 2.0 to 2.1. It's also probably why Oracle broke. But, if it's not the case, file a bug report and maybe it can be fixed for glibc 2.2.2.
Well, yes people objected to sourceforge fwd'ings to the -dev list. Hence Dave Wolfe (the guy running all the lists) is creating a list for them. So yes, I do think you're a bit too cynical Who have you been reporting these bugs to? The one you're referring to is rather well known (Paul knows about it, Cort knows about it, I think everyone knows about it.) The problem is finding time to yank yet another hw bug fix out of darwin. What machine do you have anyways. And dare I ask what "2.1.24" kernel it was? That tree took ages to finally die.
The only problem here is that Cort (the maintainer for PPC) has been sending in patches since the late 2.3 days. Hell, 2.3.49ish or so was actually up to date. There wasn't too much work being done on PPC-specific things (because the main kernel was too buggy and liked to eat FS'). But as other people have said, if you're machine isn't x86, you shouldn't be using the "main" tree anyways. It's not Linus' fault or the maintainers fault. It just happens. It's also certainly not a "War".
> It's pretty hard to keep up with nowadays. It is apparently getting worse.
Actually, as of 2.4.2preN, the difference is much smaller than it used to be (>500kB). It's still missing critical things like IDE updates, but it's not as bad as before.
What SMP box do you have? The dual G4s work rather well, and the daystar boards are still being fixed up (they almost work rather stabily). Finally, Linux (2.2.18 and 2.4.N, from the right tree of course) can read/write HFS rather well. I wouldn't use my main volume, but i've had a 32mb partition on a few machines, and diskcheck (the apple util, I think thats the name but I'm not sure). hasn't found any errors.
As someone who actually works on the PPC kernel, I do admit that there are bugs, but the other side of the coin is that hardly anyone reports these things. The developers only have a finite number of machines, and can only test what they have.
But anyways, frambuffers are working well (with an occasional problem on the wierder ATIs, or some of the undocumented apple controllers.) Serial was broken once upon a time, but that's been fixed for ages (and even made it into Linus' tree in 2.4.2pre2). I assume you're referring to "standard" IDE cards which work in 2.4. Patches do indeed get ignored, but again there's more people trying to keep track of things now.
As for the rewrites you mention, I know some of the recent ones have been so that new machines can be used and maintained sanely.
It does depend a lot on what you're doing. If you
want a nice card for driving big monitors, and getting work done, along with the occasional 3D game, I'd say go with a Matrox G400. They're really nice, well supported, and for all the features that work now and will work someday (DVD), they're a good deal. I'd stay away from the 450s for now, just because they're still rather new, and from the reviews I've seen they only really beat the 400 in price. I've had a Millennium 1, 2, G100, G200 and now a G400 and all
have worked wonderfully under linux.
Actually, no. IIRC, there are two styles for rc files. BSDish (/etc/rc.init or so, and it does everything) and SystemVish, which at least RH and Debian are. Both store their scripts in /etc/init.d (RH7 moved 'em there, /etc/rc.d/init.d in older versions.) Looking at the portmap script from woody and RH6.2, they both have the same layout (check if it exists, then see if it's start/stop/reload/restart). So yes, the rc scripts are almost identical. Different commands to do things, yes, but virtually the same format. If you can understand one, you can understand both. As for slack, I can't say.
While the .debs have a more human-readable dependancy, this isn't as big of a win as you might think. Very few people resolve missing deps in debian by hand (I never do), apt/dpkg figure it out. Personally, I think it'd rock if dh_shlibs made more rpm-ish deps (ie symbol@GLIBC_2.2, etc) since this would allow for a lot more accurate dependancies to be made.
This is sort of possible anyways. At least the first part. If a package has a .spec file in it, rpm -tb something.tar.gz will go, build and spit out /usr/src/redhat/RPMS/$ARCH/something-somever.$ARCH .rpm
This argument works just as well with debs as RPMs. The only problem being a lot more packages provide a specfile so you can rpm -ta foo.tar.gz than provide the debian dir. And while official rpms do lag behind the release, this happens with debian as well. And for those packages which don't have a specfile, it's _usually_ trivial to change the specfile (yes, you do have to dl a bit more) for the current version. Back when I had time I managed to keep a RH5.1 (originally) system up to date until I found something better to do.
Debian just lets you be lazy and not have to compile things to stay up to date.
As for the rc files, They look to be about the same as debians anyways.
Well, about the first comment, yes if you don't try and upgrade libraries and basically ignore your dependancies errors show up. You can quite easily do this on a debian system too. If the main libraries the program wants are too old, and your system doesn't have them, .debs don't help you either. It's either upgrading from 5.1 to 6.2 or whatever. Kinda like apt-get dist-upgrade, but with a bit more hassle. But when you actually listen to and use the dependancy info, .rpm is actually better than .deb
If you have access to both kinds of systems (RH6.2ish or newer and debian) do a list of dependancies on some packages. Debian will list libc6, and other things dh_shlibs or so picks up. rpm 3.0.4 (3.0.0?) will get down to all the nitty details. (Check out the yup program, it's quite good at checking all the funky deps).
Yes, but how does it compare to Blackdowns 1.3 JDK? Remember, Sun's "Linux port", at least the first round of it anyways, was re-releasing Blackdowns work, including their README file.
The Blackdown 1.3 JDK should be fine on RH7, as well as IBMs JDK, which seems much faster in the few tests I've done. And, the Blackdown JDK anyways has a -target flag, which sounds like it would compile for say, JDK 1.1.
This was one of the things we noticed when we were pulling a non profit organization (The Open Source Education Foundation). after some contemplation (and other ugly incidents) we came up with the idea of the K12 Student Pad a device that we are starting to develop. The way we see it, it should be about the size of a clip board and about 2-2.5 inchs thick, full color and run a very customized version of linux. It would interface with a new type of desk for in class use and be able to charge and network thru that desk. The other objectives we have are: Shock resistent to 10+ G's, capable of being run over by a Kenworth tractor trailor rig, water resistance to 3 meters, and be able to play 320x240 mpeg movies.
A friend of mine pointed this out this morning. It's RedHat 6.x with s/RedHat/Gentus/g and Andre Hedricks(sp?)s IDE patches applied to a 2.2.x kernel. I'm not sure about the kernel part, but those patches do add support for the UDMA/66 chipset found in the BP6. As for the 1st statement check out:
http://www.gentus.com/qig-images/image002.jpg
and
http://www.gentus.com/qig-images/image030.jpg
Um, not really. For one it's a kernel issue, and any kernel works anywhere (BenH's, which LPPC 2k is using, working on debian, lppc, ydl and anybody elses dist for that matter) Also, the original, Well it's booting, was done long before YDL did any sort of patching.
More importantly, we gave LinuxOne a 1999Q3 CD at MacWorld SF recently (Yes, they were there for some reason).
It has OpenSSH 1.2.2 and OpenSSL 0.9.6, iirc.
Actually, forgetting for a moment this is a totally made up rumor, it could be interesting. Everyone so far seems to assume Apple porting over OS X or whatever to x86. Why? Crusoe is not an x86 chip. If apple went to another architecture they loose all their old apps, and piss off lots of customers. But there's nothing stopping them from helping transmeta do a PPC layer. Which gives you compatibility with all your existing apps, still pretty fast CPUs (in theory) and no motorola. And, assuming Phoenix didn't have to do too much to get their BIOS happy, "porting" OpenFirmware over shouldn't be too much trouble either (just add in the crusoe specific stuffs..) Sounds good too me.
Too bad it's from MOSR.