The only problem I ran into was in smbfs. For anyone out there who hasn't got even the modicum of C it takes to figure it out, the solution is to add a semicolon at the end of line 91, in linux/fs/smbfs/inode.c ("insert_inode_hash(result);") (I was going to include a patch, but Slashdot mangles it).
On a box with 128M or more, I'd just fire it up and forget about it. With "only" 64M of RAM, though, there's a noticable performance hit, especially when there are other memory hogs running, like Netscape or the GIMP.
The screensaver idea'd be perfectly fine if I was running a Windows box, or other system that was designed to be used primarily from the console. I'm using Linux, though, with a permanent 'net connection, and how heavily I'm using the box has little to do with whether or not I'm in front of the machine.
I suppose I could set up a cron job to look for aliens between 0200 and 0600, when there's very probably no one using the machine, and let RC5 have my spare cycles the rest of the time. Or maybe I'll just get more memory. RAM prices are coming down again...
Er... excuse me? 2.0.36 hasn't been out for any 436 days...
Earlier this week, I had to reboot one of my machines (because of a failing hard disk). It had been up for 273 days, running 2.0.35, because that was the latest stable kernel when I brought it up...
"Some memory". Yeah, that's one way to put it. Last version I tested used in the neighborhood of 20M. That's why I'm still running RC5. I've got plenty of spare cycles, but I don't have 20M of spare RAM.
Yup. I grabbed both of them, for different machines. There were already three pre-patches out towards 2.3.1, anyway... the 2.3.1 final patch presumably would contain all of that stuff, plus the vital bit that rushed 2.2.9 out.
I suppose I could diff the two patches and see how much overlap there really is, but I'm too lazy to figure out the switches that would give me some useful information...
According to "finger @linux.kernel.org", 2.3.1 is out as well. I suspect that whatever problem (I heard something about filesystem corruption?) that caused the quick release of 2.2.9 encouraged a similar release on the 2.3 tree... 2.2.8 and 2.3.0 are identical, after all...
And anyone who's got a problem with letting people know that there's a new dev kernel out can flame away. I've got a thick skin.
That's the only difference between 2.2.8 and 2.3.0. The 2.3.1prex patches contain further changes.
Re:Simple solution to the "kernel news" controvers
on
Linux 2.3.0
·
· Score: 1
What, you mean like the little slashbox that shows the latest stable and devel kernel numbers? (It's called "Linux HQ Kernel Versions" or something like that.)
You can also finger @linux.kernel.org, and get the same information with less propagation delay.
I like having the posts on Slashdot, though, because, although I usually finger kernel.org at least once a day, especially when I get the feeling that a new kernel release is imminent, there's only been about three times where I found out about it before it was posted on Slashdot. And, given that I do all my kernel testing on a 386-40, I need all the lead time I can get...:) People who don't want to read the articles can just skip over 'em. It's not hard; I do it all the time with articles I'm not interested in.
And, regardless, I think the opening of the 2.3 development series qualifies as a major, important kernel update. The patch itself may not consist of more than a version number change, but it's the equivalent of Linus firing the starting gun for the race to get all those cool new features implemented. It's also a signal that the developers think that 2.2 is really solid and stable now, and the main development effort can be concentrated on adding new features for the next stable release.
This post was intended to be a mildly sarcastic one-liner, and it seems to have gotten a little out of hand, so I'll shut up now...
Re:Pre-patch for devel kernels? WTF?
on
Linux 2.3.0
·
· Score: 1
That's the point of pre-patches for stable kernels. The point of pre-patches for dev kernels seems to be slightly different. They're more to get the code out to the people who might be interested so they can smack it around and get it mostly working so that the release development kernels stand a good chance of at least compiling and probably even running. Dev kernels are basically pre-patches for the next stable kernel series, anyway, so their pre-patches are really pre-patches for pre-patches, with a corresponding decrease in expected reliability...
Re:WTF? Why install 2.3.0? Exactly the same as 2.2
on
Linux 2.3.0
·
· Score: 2
I've got one machine running 2.3.0 now, and two more that I'm planning on having on 2.2.8 before the day is up. The difference between them is that the 2.3.0 machine is my guinea pig box, and it's going to be upgraded to 2.3.1 when it comes out and follow the dev tree. The 2.2.8 machines will be upgraded to 2.2.9 and stay on the stable tree until 2.4/3.0, whichever comes first. Yeah, the only difference is the version number, but having the wrong version number will make a difference when it comes to getting the next patch applied cleanly.
And the guy who started this has done the rest of us a favor by installing 2.3.0. He found a bug (or maybe it's just a misfeature) where the version number change causes certain modules not to work. Would you rather he'd stuck with 2.2.8 and the bug had gone undiscovered until he installed 2.4.0 a year down the road, expecting something with all the bugs worked out, and discovered that his sound didn't work?
Yeah, I know, I'm sure someone else would have discovered something that blatant long before 2.4 made it out the door, but the point remains... people using dev kernels is what makes the bazaar model of development work. "Release early, release often," doesn't do much if only a select few are actually _using_ those releases.
If you want cathedral-development free-source Unix, you know where to find *BSD...
Well, if it was to accomplish anything useful, they'd pretty much have to open their code... it's hard to fix bugs in software you don't have the source for.
If you meant "find", rather than "fix"... I'm still not sure it would accomplish much of anything. I mean, there are enough MS users out there that someone has got to be reporting the bugs... They _have_ to know about them. They just aren't fixing them.
As Bill Gates said, there are no significant bugs in Microsoft's software. Everyone's just using it wrong...
It was calm, rational, and in general was pro-Linux without sounding rabidly fanatical. There were a few minor inaccuracies, but nothing serious... and most of those few were true statements that had inaccurate implications.
My main complaint is that they used the "word" "educative". But, then, it's oriented towards managers...
They mentioned that Civ:CTP was going to be the first game released simultaneously for Windows and Linux. This is unfortunately, untrue. The Windows version has been out on store shelves for weeks now, and us Linux junkies still haven't gotten our Civ fix...
Maybe I'll go play some FreeCiv to hold off the shakes for a little longer...
Heinlein's one of my favorite authors, but I have to say that I have yet to see any movie based on a Heinlein book that was even close to decent. Star Wars, on the other hand, made a great set of movies.
The thing to keep in mind is that Star Wars wasn't intended to be hard-core science fiction. Futuristic mythology might be a better term for it.
That's actually a two-keystroke operation for me, anyway. I've got my left Evil-Empire key bound to a fvwm popup menu, which comes up with the first entry - "Local Eterm" - selected. So one keystroke to pop up the menu, Enter to activate the selection, and, if I'm lucky, it'll even come up in focus. If not, well, Alt-Shift-Arrows'll focus it pretty quickly.
Maybe OGR will help reverse the trend, but as things stand now, d.net is, if not dying, at least not growing nearly as fast as it used to, and a lot of older members are dropping out.
My own team, for example, despite my best efforts, is down to about 10 active members, from a peak of 40 or so. Some of those have been people who cracked for a few days and then quit, which wouldn't worry me. Now, however, we're starting to lose people that have been cracking for many months, because they simply don't care any more.
We've been working on RC5-64 for more than a year and a half now, with nothing more to show for it than a "percent checked" bar still in the single digits. At this rate, the best we're going to prove is that 64-bit encryption is pretty darned strong, which isn't exactly a goal to generate excitement in the masses.
I've been doing d.net since the last couple months of RC5-56 - approaching two years now. I'm running the client on every box I've got (with the exception of my Novell server, which I gave up on after the first two times the client crashed it). My machines have been responsible for some 100,000 RC5 blocks. I'm currently cranking out 1.5 - 2Mk/s, which is enough to keep my ranking in the top quarter of active participants.
And I'll drop d.net like a rock if SETI@Home manages to produce a client that uses less than 20 fscking meg of RAM. They're at least doing something potentially useful. RC5-64 isn't.
> I see no reason for X if you have a superior GUI already.
Because X isn't a GUI. fvwm2 is a GUI. Enlightenment is a GUI. Windowmaker is a GUI. X is a graphics transport protocol. There's no reason the Mac GUI couldn't make use of X, keep all of its famed "ease of use", and be network-transparent, too.
And that last is the real reason to have X. We're living in a networked world, and it's only going to become more so. In that world, the ability to sit in front of one machine and work with another as if it was right there is going to be increasingly valuable. Unix, between the power and easy remote use of its command shell and the network-transparency of X, has had this ability for many years. MacOS and Windows don't. As a result, MacOS and Windows are stuck in client-server or host-terminal relationships, rather than the much more powerful "one network, one computer" model Unix gets closer to with every increase in network bandwidth.
Slashdot Mirror
The only problem I ran into was in smbfs. For anyone out there who hasn't got even the modicum of C it takes to figure it out, the solution is to add a semicolon at the end of line 91, in linux/fs/smbfs/inode.c ("insert_inode_hash(result);") (I was going to include a patch, but Slashdot mangles it).
On a box with 128M or more, I'd just fire it up and forget about it. With "only" 64M of RAM, though, there's a noticable performance hit, especially when there are other memory hogs running, like Netscape or the GIMP.
The screensaver idea'd be perfectly fine if I was running a Windows box, or other system that was designed to be used primarily from the console. I'm using Linux, though, with a permanent 'net connection, and how heavily I'm using the box has little to do with whether or not I'm in front of the machine.
I suppose I could set up a cron job to look for aliens between 0200 and 0600, when there's very probably no one using the machine, and let RC5 have my spare cycles the rest of the time. Or maybe I'll just get more memory. RAM prices are coming down again...
Er... excuse me? 2.0.36 hasn't been out for any 436 days...
Earlier this week, I had to reboot one of my machines (because of a failing hard disk). It had been up for 273 days, running 2.0.35, because that was the latest stable kernel when I brought it up...
"Some memory". Yeah, that's one way to put it. Last version I tested used in the neighborhood of 20M. That's why I'm still running RC5. I've got plenty of spare cycles, but I don't have 20M of spare RAM.
Yup. I grabbed both of them, for different machines. There were already three pre-patches out towards 2.3.1, anyway... the 2.3.1 final patch presumably would contain all of that stuff, plus the vital bit that rushed 2.2.9 out.
I suppose I could diff the two patches and see how much overlap there really is, but I'm too lazy to figure out the switches that would give me some useful information...
But my kernel's done cooking... reboot time...
Whichever way you decide to go, there's no need to wait... (see my previous post above). :)
According to "finger @linux.kernel.org", 2.3.1 is out as well. I suspect that whatever problem (I heard something about filesystem corruption?) that caused the quick release of 2.2.9 encouraged a similar release on the 2.3 tree... 2.2.8 and 2.3.0 are identical, after all...
And anyone who's got a problem with letting people know that there's a new dev kernel out can flame away. I've got a thick skin.
That's the only difference between 2.2.8 and 2.3.0. The 2.3.1prex patches contain further changes.
What, you mean like the little slashbox that shows the latest stable and devel kernel numbers? (It's called "Linux HQ Kernel Versions" or something like that.)
:) People who don't want to read the articles can just skip over 'em. It's not hard; I do it all the time with articles I'm not interested in.
You can also finger @linux.kernel.org, and get the same information with less propagation delay.
I like having the posts on Slashdot, though, because, although I usually finger kernel.org at least once a day, especially when I get the feeling that a new kernel release is imminent, there's only been about three times where I found out about it before it was posted on Slashdot. And, given that I do all my kernel testing on a 386-40, I need all the lead time I can get...
And, regardless, I think the opening of the 2.3 development series qualifies as a major, important kernel update. The patch itself may not consist of more than a version number change, but it's the equivalent of Linus firing the starting gun for the race to get all those cool new features implemented. It's also a signal that the developers think that 2.2 is really solid and stable now, and the main development effort can be concentrated on adding new features for the next stable release.
This post was intended to be a mildly sarcastic one-liner, and it seems to have gotten a little out of hand, so I'll shut up now...
That's the point of pre-patches for stable kernels. The point of pre-patches for dev kernels seems to be slightly different. They're more to get the code out to the people who might be interested so they can smack it around and get it mostly working so that the release development kernels stand a good chance of at least compiling and probably even running. Dev kernels are basically pre-patches for the next stable kernel series, anyway, so their pre-patches are really pre-patches for pre-patches, with a corresponding decrease in expected reliability...
I've got one machine running 2.3.0 now, and two more that I'm planning on having on 2.2.8 before the day is up. The difference between them is that the 2.3.0 machine is my guinea pig box, and it's going to be upgraded to 2.3.1 when it comes out and follow the dev tree. The 2.2.8 machines will be upgraded to 2.2.9 and stay on the stable tree until 2.4/3.0, whichever comes first. Yeah, the only difference is the version number, but having the wrong version number will make a difference when it comes to getting the next patch applied cleanly.
And the guy who started this has done the rest of us a favor by installing 2.3.0. He found a bug (or maybe it's just a misfeature) where the version number change causes certain modules not to work. Would you rather he'd stuck with 2.2.8 and the bug had gone undiscovered until he installed 2.4.0 a year down the road, expecting something with all the bugs worked out, and discovered that his sound didn't work?
Yeah, I know, I'm sure someone else would have discovered something that blatant long before 2.4 made it out the door, but the point remains... people using dev kernels is what makes the bazaar model of development work. "Release early, release often," doesn't do much if only a select few are actually _using_ those releases.
If you want cathedral-development free-source Unix, you know where to find *BSD...
Well, if it was to accomplish anything useful, they'd pretty much have to open their code... it's hard to fix bugs in software you don't have the source for.
If you meant "find", rather than "fix"... I'm still not sure it would accomplish much of anything. I mean, there are enough MS users out there that someone has got to be reporting the bugs... They _have_ to know about them. They just aren't fixing them.
As Bill Gates said, there are no significant bugs in Microsoft's software. Everyone's just using it wrong...
(Methinks someone's in denial...)
10^6 = million
10^9 = billion
10^12 = trillion
10^15 = quadrillion
10^18 = quintillion
10^21 = sextillion
10^24 = septillion
Assuming you're American. Elsewhere, YMMV.
Someone's been reading "Diamond Age"....
It was calm, rational, and in general was pro-Linux without sounding rabidly fanatical. There were a few minor inaccuracies, but nothing serious... and most of those few were true statements that had inaccurate implications.
My main complaint is that they used the "word" "educative". But, then, it's oriented towards managers...
I commonly call my car "my big ol' V-8 wagon"...
They mentioned that Civ:CTP was going to be the first game released simultaneously for Windows and Linux. This is unfortunately, untrue. The Windows version has been out on store shelves for weeks now, and us Linux junkies still haven't gotten our Civ fix...
Maybe I'll go play some FreeCiv to hold off the shakes for a little longer...
Heinlein's one of my favorite authors, but I have to say that I have yet to see any movie based on a Heinlein book that was even close to decent. Star Wars, on the other hand, made a great set of movies.
The thing to keep in mind is that Star Wars wasn't intended to be hard-core science fiction. Futuristic mythology might be a better term for it.
It's Bruce Campbell, with a "P", dammit...
ftp6.us.kernel.org has it.
Actually, Jeff Goldblum's computer was a Powerbook, so it must have been MacOS that he infected them with that brought their systems down.
That's actually a two-keystroke operation for me, anyway. I've got my left Evil-Empire key bound to a fvwm popup menu, which comes up with the first entry - "Local Eterm" - selected. So one keystroke to pop up the menu, Enter to activate the selection, and, if I'm lucky, it'll even come up in focus. If not, well, Alt-Shift-Arrows'll focus it pretty quickly.
Oh, yeah, and that's quick and easy to say. :)
Basic problem with voice recognition for geeks. Code is easy to type, hard to speak.
Maybe OGR will help reverse the trend, but as things stand now, d.net is, if not dying, at least not growing nearly as fast as it used to, and a lot of older members are dropping out.
My own team, for example, despite my best efforts, is down to about 10 active members, from a peak of 40 or so. Some of those have been people who cracked for a few days and then quit, which wouldn't worry me. Now, however, we're starting to lose people that have been cracking for many months, because they simply don't care any more.
We've been working on RC5-64 for more than a year and a half now, with nothing more to show for it than a "percent checked" bar still in the single digits. At this rate, the best we're going to prove is that 64-bit encryption is pretty darned strong, which isn't exactly a goal to generate excitement in the masses.
I've been doing d.net since the last couple months of RC5-56 - approaching two years now. I'm running the client on every box I've got (with the exception of my Novell server, which I gave up on after the first two times the client crashed it). My machines have been responsible for some 100,000 RC5 blocks. I'm currently cranking out 1.5 - 2Mk/s, which is enough to keep my ranking in the top quarter of active participants.
And I'll drop d.net like a rock if SETI@Home manages to produce a client that uses less than 20 fscking meg of RAM. They're at least doing something potentially useful. RC5-64 isn't.
> I see no reason for X if you have a superior GUI already.
Because X isn't a GUI. fvwm2 is a GUI. Enlightenment is a GUI. Windowmaker is a GUI. X is a graphics transport protocol. There's no reason the Mac GUI couldn't make use of X, keep all of its famed "ease of use", and be network-transparent, too.
And that last is the real reason to have X. We're living in a networked world, and it's only going to become more so. In that world, the ability to sit in front of one machine and work with another as if it was right there is going to be increasingly valuable. Unix, between the power and easy remote use of its command shell and the network-transparency of X, has had this ability for many years. MacOS and Windows don't. As a result, MacOS and Windows are stuck in client-server or host-terminal relationships, rather than the much more powerful "one network, one computer" model Unix gets closer to with every increase in network bandwidth.