> I have a palm V which I've had for maybe 18 months, as you say using and charging it every day.
I don't want to have to charge it every day.
How long will a full charge last you? A couple of days of use? If it reliably lasts a week of heavy use, then maybe it would be servicable for what I want. Still, I like the ability to roam with my palm, and not have to worry about where to plug it in at night. That is why I chose my IIIe over the V. AAA's last months, and can be purchased cheaply anywhere I'm likely to go. And for the case where I can't buy AAA's (say...camping), I can pack an extra pair in less room than a charger would take, and again I won't need a plug.
To me, the only downside of using AAA's is that it makes for a thicker Palm. I wish someone would up and define a new thin, flat battery standard so that I could still use alkaline's in something thinner than a AAA.
As for the new palms...I'm glad they are moving to USB, but I'm a bit suspicious of this new port. I would appreciate being able to view big ebooks on my palm, but I resist the move towards copy control. We'll see how open it turns out. They way things are going, I'm not terribly optimistic.
--Lenny
Time for some education on computer architecture..
on
Emergence of SMT
·
· Score: 5
> SMT? Blow it out your ass.
Rather unnecessary, don't you think? I don't think you would be quite so hostile to SMT if you had a better understanding of it.
Time to do some informing...
> Surely this 'virtual-multi-CPU' system can only decrease the sheer number of operations per second a CPU of a given size/speed can do?
This statement doesn't make much sense. I think you mean that a CPU which spent the die area on additional functional units as opposed to SMT support could achieve a greater MIPS value. This is true, but only for theoretical MIPS. Simply adding more functional units to modern chips, would *not* improve actual performance. Explanation follows...
> The overhead - whether it be in sacrificed MIPS or die area, of distributing instructions among execution units is going to be significant, compared to a maxed-out single core design.
So you are stating that implementing SMT comes at a cost in die area? Of course it does, but the important point is that using that die area instead to add more conventional execution units would *not* increase the performance of the processor. Why, you ask? There is a limited amount of instruction level parallelism available in a single thread of program execution. Current wide-issue superscalars get something on the order of 2.3 dispatches per clock, despite the fact that they have the *capability* to issue far more. The processor simply can not find enough independent instructions to keep it's functional units full. If memory serves, the Athlon is a 9-issue core. You could add functional units up to 12-issue or more, but your actual dispatch rate would still be around 2-3 per clock. While your theoretical performance would increase your actual performance would remain stagnant.
So, current software does not exhibit enough parallelism to keep the functional units in even current processors busy. SMT proposes to increase available parallelism by issuing instructions from *multiple* threads at once. Instructions from different threads are guaranteed to be independent, so if you have n threads running at once, your number of available instructions for dispatch each clock is improved about n times. Of course, this method has a cost in complexity and area -- now the CPU has to have knowledge of threads, and keep a process table on die. However, provided many threads are run at once, this *greatly* increases the utilization of the processor's resources, and thus the performance of the part.
> Since reading and writing to various RAM caches are the biggest bottlenecks in the current PC architecture, adding more units is just going to lead to increased contention for these resources.
...this is a valid point. SMT particularly increases the burden on instruction fetch and cache, since it is pulling from several different streams at once. However, there are methods that can somewhat compensate for the contention of resources introduced. Now, you have multiple threads available at all times. So, when one thread stalls on a cache miss, the processor can dispatch a different thread to run while the cache miss on the first is being serviced. This effectively hides the latency of the cache miss since the processor is able to do useful work during the service. You see, it's all about keeping those functional units busy.
> So many CPU cycles are wasted with the current generation of software that it seems a bit pointless increasing the number of potential instructions you could perform..
If you believe this, then you should be pro-SMT. SMT doesn't address increasing potential instructions performed per second. Instead, it is an attempt to close the gap between *actual* performance and *theoretical* performance by keeping more of your processor busy.
>you have to question the thinking behind such a modification.
The FHS (Filesystem Hierarchy Standard) lays out the basic organization of a compliant filesystem. The differences between flavors of init scripts run deeper than simply where the scripts are located within the filesystem. Thus, runlevels are beyond the scope of the FHS.
While inappropriate for the FHS, runlevels may well be treated in the more comprehensive LSB. I am unaware if this is on the agenda of the LSB, but the current discrepancy between systems is certainly an annoyance. However, standardization of start up scripts may prove difficult as it involves treading through a few holy wars. Some of the old SysV / BSD schism carries on in the Linux camps, and this partially explains the different runlevel schemes in use today.
Personally, I think rc scripts *should* be homogenized, and the LSB may be the appropriate body to push this through. I don't think the current divide is buying us much other than headaches. However, presently the LSB seems more concerned with binary compatibility at the application level: glibc versioning, ABI standardization, etc. This is a rather important topic as third party companies begin porting to "Linux", which they quickly find is segmented into ~5 pretty much compatible systems. This isn't such a big deal if you have source code, but can be a big hair mess for binary-only applications. Of course, some would argue that they don't *want* binary only applications on their system, but I'll leave that debate to the Slashdot masses...
Mine was one of the "Caviar" 1.6 GB drive, although I don't remember the model number. Yes...quite old.
A quick google search pointed me toward the Linux UDMA how-to.
http://www.linux.com/howto/mini/Ultra-DMA-9.html
The blacklist:
*Western Digital WDC AC11000H, AC22100H, AC32500H, AC33100H, AC31600H - all versions
*Western Digital WDC AC32100H revision 24.09P07
*Western Digital WDC AC23200L revision 21.10N21
...note that this is the *entire* blacklist. It seems that the other drive vendors have their acts together.
Keep in mind that these drives should run just fine as long as you *don't* enable UDMA. I was unaware of this, and that's why I got bit. Also, I'm not sure how up to date or comprehensive the list is, but atleast it provides a place to start.
Having a WD drive bit me pretty bad about a year ago. A week or so after a kernel recompile, I wound up with filesystem corruption, even though I was running a stable kernel. I take my computer very seriously, and though I was able to recover my important data, losing the filesystem hurt *bad*.
My faith in Linux took a big hit after that. The only explanations for that error were 1) hardware failure (seemed unlikely) or 2) serious kernel bug. I contemplated migrating to FreeBSD, but was informed that much of the IDE code between Linux and BSD is shared, so any fundamental bug would probably follow me to the new platform. So, I just rebuilt my system and carried on.
A few months later I was reading Kernel Traffic, and someone posted a filesystem corruption problem with the exact same symptoms, using the exact same WD hard drive. One of the hackers identified the source of the problem -- it was Western Digital.
Some models of WD drives are advertised as "UDMA compatible". That is, you can enable UDMA and they will run. However, WD is sidestepping the fact that the drives are *not* UDMA "compliant". Apparently a part of the UDMA spec is the transmission of periodic CRC checks to detect and correct errors. Some WD drives will operate in this mode, but blow off the CRC checks. This is suicidal. If the drive is used in UDMA mode (which it claims compatibility with) you *will* get data corruption...it's just a matter of when and how bad.
Thinking back before the failure, sure enough, I had enabled UDMA in the kernel, looking for a speedup from my UDMA "compatible" drive. WD had mislead me in the features of that drive, and it resulted in data loss. I view this as highly irresponsible on their part, and I will certainly not buy from them again.
One of Sun's headlines is "SUN SHATTERS INDUSTRY PRICE BARRIER WITH FIRST 64-BIT WORKSTATION AT $995". You'll note they are touting the "64-bit" buzzword as much as possible before the new Intel and AMD designs comes out.
But even discounting the new designs from the x86 houses, haven't there been inexpensive Alpha platforms? I know the Multia was supposed to fill a similar role. They are quite dated now, but I expect at the time of their sale, their price tags were around $1K. Alpha's are definitely 64-bit.
Can't you just smell the fear Sun coming off of Sun. Free Unices on commodity hardware is making their offerings look worse and worse. This new product line strikes me as a last-ditch attempt to lay ownership to the low-end workstation market before Linux does...and before commodity processors can claim "64 bit" as well. Many would say it is already too late. Linux has built up prestige now, it just needs a company with a solid rep (say...IBM) selling support to fully displace the older Unices. BSD could pull the same stunt.
If Sun wasn't so protective of Solaris and the high margins that proprietary systems allow, they might see Linux as an opportunity. By embracing Linux now while they still have a good name, they could become *the* Linux company in the coming years. If they stick to their current model, and don't pick up Linux (or do it too late), I can't see them remaining relevant. The Unix landscape has just changed too much.
You are correct that Republicans are, in a very generic sense, "pro-business". Of course, Democrats are as well, these days, so that doesn't say a whole lot. For all the stomping, and hand-waving, I see virtually no difference between the two major American parties.
But this statement:
> I imagine the smary nerdiness of GAtes will probably annoy good old boy Dubya
...is unfounded, and ridiculuous. Bush went on record during the election as siding with the MS in the DOJ case. He stated that if he won the election, he would do whatever was necessary to "protect companies' right to innovate", or whatever the line from Redmond was at the time. I was aghast.
Still, I'm not too worried. Much as I dislike MS, I've never much believed in the court case. MS is guilty as sin, but I don't think a court decision could ever remedy that. Eventually, MS will choke on its own vomit. The day will come when consumers realize how much MS is toying with them, and slowly they'll drift away.
Besides, I think the OS is rapidly losing the limelight as far as computing goes. I agree with Cringely that MS has peaked and that this new decade will be the decade of Cisco. If I had money lieing around, I'd be buying Cisco stock...
> People always seem to forget that if there is other life out there, that it'd most likely be *completely* different from us.
I agree. I think a lot of the populace is poisoned by Star Trek, where aliens are, by and large, humans with face paint. There is no reason to expect extra-terrestrial life to resemble us.
> To the point that most likely the biggest challenge in finding other life in the universe will be recognizing it as life.
That's ridiculous. We know *exactly* what life is, and how to recognize it. How, you ask? It's quite simple...humans *invented* life. "Life" is merely a concept and a word. It is a notion that humans invented to suite our own needs.
There is a precise scientific definition of what constitutes "life"...we define something as "living" if it meets the 7 (or so) requirements accepted by the scientific community. For a while there was a debate among scientists whether the definition should be changed to include viruses. Last I heard, viruses only met 5 of the 7 points. Hence, they are not technically living creatures. No problem there...life means whatever humans want it to mean. It's just that some humans felt "life" would be a more *useful* category if it included viruses. I see their argument.
Anyway, my point is that many people don't understand that "life" is an entirely human creation -- purely an aspect of human language and science. There is no universal notion of living things. It's just a useful category that humans have created. If we encountered an alien species, there is no guarantee that they would have a similar notion to "life".
It's been a really long time since I've seen one of those...
There was an old joke in the industry that TI had grade A engineering and grade D marketing. They had all sorts of good products that no one used, and they suffered as a result. I think a lot of their lifeblood came from their early patents, which they gladly licensed to other companies.
Of course that was the old TI. Recently they've totally recast themselves as a DSP company. They sold off product lines in most of their old markets, and focused on what they saw as an emerging market with the potential to be huge. It was a bold move, and it seems to have paid off for them. TI is doing pretty well these days, and it looks like they were right about the DSP market.
a few years ago at (I believe it was) Linuxworld. In an effort to finally settle the age old debate, there was a paintball battle between Team Emacs and Team vi. O'Reilly supplied team shirts, with the respective book covers on the front. There was a fair amount of trash talk on Slashdot before the event. Mind you, these were the early days of Slashdot, and most readers had actually used both.
The match went to Team vi. It is worth noting that they fielded a larger team. To this day, I feel guilty about not attending that conference -- it's quite obvious that Team Emacs needed me.
Congrats...one of the best old-style trolls I've read on Slashdot in a long time.:) I wonder how many folks will bite...
Atleast, I sure hope this is a troll. It *is* curious that it should come from such a high user ID. But, surely with a line like "resource-hog abominations on us like KDE, Gnome and TWM" it is. Exploiting the fact that newbies probably don't know about TWM, methinks? Nice touch.
Anyone want to start betting on how many angry replies this generates?
> you know according to linus' our words a large patch like ReiserFS shouldn't have made it in.
...except that he had stated earlier that ReiserFS was on the slate for 2.4.1 . So, there is a bit of a discrepancy there, but given that the ReiserFS statement was specfic and the 2.4.1 statement was general, it seems reasonable to trust the specific.
Of course, treating Linus's quotes as gospel is a bit silly, anyway. Believe it or no, it *is* possible for Fearless Leader to make self-contradictory statements, and he has certainly gone back on his own statements before.
> Another thing is that apparently 2.4 was failing to boot on i386 machines. It had something to do with the CPU's cache not being large enough i belive.
This issue has been tracked down. Of note is the fact that it affects only a very small subset of 386's. If I recall correctly from Kernel Traffic, there was a recall on those early 386's anyway.
I've got a somewhat similar story, actually. I randomly met Larry Ewing recently. For those new to the Linux world, this is that guy that, among other things, drew THE Linux penguin that you still see pasted all over the web. The conversation went something like this...
Me: "So, you do a lot in the Linux world?"
Him: "Well, you know that penguin? I was the one who drew it."
Me: "Oh, you're Larry Ewing."
Him: "That's right."
Me: "Dude, that penguin is *way* over used."
Him: *shrugs*
...I kinda felt bad afterwards, because he seems like a nice guy. I *was* pretty jazzed to meet a "name" in the Linux world. And it's not his fault that his art is overused. Still, I just had to say it.:)
> Seems to me that it'd be pretty cool to write to the native Crusoe architecture rather than going through the x86 ``emulation''. Does anyone know if it's even possible to bypass the emulation at all, and write native machine code
Just about every Crusoe posts comes standard with one or two of these questions. Actually, I don't know the answer, but I expect it is *not* possible to write to the "native" ISA of the Crusoe chips. In so doing, you would be circumventing important architectural features of the chip, which operate in their ultra-low-level ISA emulation software.
But most importantly, even if you could, they do not *want* you to. Their code-morphing software also performs some optimizations, which would be thrown out the window if you went "native". More importantly, though, native could would be irrevocably tied to *that implementation* of the Crusoe. Transmeta is under no obligation to build the next Crusoe with the same ISA, and probably won't. Since they are emulating another ISA, the physical architecture is only seen by their software, thus they can tweak the architecture as much as they like between revs without having to worry about breaking binary compatibility. As any design engineer knows, this is a Thing of Beauty, and a luxury no other company is allowed. If people started programming native, they would lose that luxury.
So, while writing straight to the Crusoe silicon (if possible) may be fun as a hack, it would not result in maintainable software. Moreover, it is in Transmeta's best interests to discourage such behavior
> This story does clearly not flatter to RMS, who showed us again his desire to GNUlize anything out there, so that he, personally RMS, will be remembered as the one who created a great project(tm).
Mmm...flame bait on a Saturday morning. You know, Slashdot really *was* nicer in the old days when it wasn't fashionable to bash RMS at every turn and drone on with "what's the use?" anytime *any* new tech is announced. Ahem...
What is your evidence that RMS is trying to GNUlize things? The tired Linux GNU/Linux argument? RMS has explained his position on that quite clearly. If people never hear about GNU, then they are not going to hear about software freedoms. Open Source is nice and all that, but RMS is trying to educate users to value their freedom. The "Linux" movement is not trying to do that. So, people could be using Linux and GNU and have no idea *why* the system was constructed and *what* it represents. RMS and others would like to ensure that doesn't happen.
I don't think that RMS is seeking personal attention. I think he just tries to publicize GNU. Presumably, he thinks GNU is important since he has made it his Life's Work. RMS isn't the most diplomatic character, but I greatly respect the GNU project, both on a technical and philosophical level.
> The one thing I want to see between now and 2.6/3.0 is ReiserFS replacing ext2
It sounds likely that ReiserFS will make it into the kernel sometime 2.4.x, perhaps early in the lifecycle. And once one journalling filesystem goes in, the rest will come rather quickly. Quite a bit of the difficulty has been in introducing journalling features into the VFS layer. This is code that will be reused for every journalling-style filesystem implemented.
Also, once ReiserFS becomes stable, it will not necessarily replace ext2fs. I expect ext2 will be around for quite some time, and will remain the default on installs for some time.
Every time you encounter an employee from one of these companies (IBM, Intel, Matsushita, Toshiba), spit on him. When he flies into a rage and demands an explanation, tell him that his company is trying to enslave consumers everywhere. Pretty soon, no one will work for these companies.
...I'm not sure whether or not I'm kidding.
--Lenny
Berlin: not going anywhere fast.
on
GTK+ without X!
·
· Score: 5
You know, I used to follow Berlin. I was hopeful that it might provide the replacement for X within my professional lifetime. I have since given up hope.
Berlin development is moving at a snail's place. They don't have just a whole lot of people working on it, and I'm not sure they have *anyone* working on it full time. While the attempt is certainly noble, I don't think it's going anywhere.
More importantly, even if they manage to finish the project and come out with a reasonable, clean replacement for X, how are they going to persuade the industry to use it? There is a ridiculous amount of code written for X. To make any inroads they are going to have to have backwards compatibility with X, in which case they've moved to a new house, but carried the old baggage with them.
I certainly do not believe the commercial Unix vendors are going to embrace such a new development. Would the free Unix distros be confident enough to break compatibility and go their own way? I don't see the balance of power between open / commercial shifting that quickly. And so far I have seen zero support of Berlin from any commercial entities (even companies like Red Hat).
If Berlin is used, I expect it will be in "fringe" applications first, not mainline workstations. Particularly, embedded applications might pick it up. They have a much smaller pool of software to tote around, and would probably be happy to have a graphics system nicer, and hopefully smaller, than X.
To bring this to a close, as "cool" as Berlin's feature sheet may sound, the software is far from complete, is advancing slowly, and will face serious obstacles once it *is* complete. I, personally, have given up hope on Berlin. I do not think it will replace X. My hopes lie instead with XFree86. There is much that can be done in the way of gradually extending X, and deprecating old features. Over time, they can drift X towards a cleaner system, relegating cruft to libraries which get loaded less and less often. This is less inspiring, but probably more feasible.
The BSD's don't necessarily share code, even on simple packages like "ls". They all have their own package, and while it may be true that they steal back and forth, there is certainly a lot of duplicated effort. In the case of OpenBSD, they want their own versions for a simple reason -- they audited them, and they trust them. But for the other BSD's, there isn't a particularly good reason for the redundency.
Recently I was listening to a recording of a table discussion at some BSD conference. One guy brought up this very point: how in the Linux world, all the distros send bugfixes to a single maintainer -- GNU for tar, Apache for httpd, or whatever. That way, it was easier for all distros to receive the benefit. Debian / Red Hat / whatever all just use the same code. (within bounds, of course).
Before this guy even finished his point, 3-4 other guys on the panel jumped on him, practically shouting. It was quite clear that they didn't like the idea of common packages one bit. I didn't even hear any arguments, they just 1) wouldn't consider cooperating like that 2) didn't like being compared to Linux.
No justification provided: those guys were just being close-minded and vicious. I lost a lot of respect for the BSD's right there.
--Lenny
gcc and pgcc are very different...
on
KDE 2.0.1 is out
·
· Score: 1
>I usually compile both XFree 4.0 and the kernel with -O6 (and with -fexpensive-optimizations) using GCC version 2.95.2, and havent had any problems at all so far.
The above poster was compiling with pgcc, which optimizes very aggressively, periodically breaking code. In the general case, I would not call pgcc a very usable compiler. It is *definitely* not meant to compile the Linux kernel. For particular purposes, it may be worth using, but I think a lot of the performance gap between gcc and pgcc has been closed in recent releases.
And, if I recall, gcc treats all -O values above 3 the same. So, -O6 will produce the same code as -O3. Actually, that may have changed since egcs remerged, but if so I haven't heard about it...
>Remember the wise words of RMS:
Free software has not to be free as in free beer.
Ah, but OpenBSD, like all BSD's, is *not* free software. The licensing is (surprise, surprise) BSD-style, which qualifies as open source, but not as free software in the notion defined by RMS / GNU / FSF.
Stallmanism aside, I greatly respect OpenBSD as a project and I agree wholeheartedly that it should be supported.
I think I'll buy a T-shirt rather than a CD, though...
I'm shocked at how many people don't know about GNU's online manuals. I find them extremely helpful, and use them routinely.
Also, there are gobs of docs for general Unix/Linux apps, in varying states of update, of course. Check linuxdoc.org for some pointers.
As for documentation for an entire *system* all at once, I know of no good source for generic linux distros. The BSD's have a bit of a leg up there, because they control the entire distribution, rather than a few components.
Or maybe not...I recently pulled up Debian's online user guide, and it is really quite helpful, even if terse. I'd put it about on par with FreeBSD's user guide. The one thing about BSD doc that I envy, though, is the online manpages. Somewhere on FreeBSD's site you can do a query on any FreeBSD command, and it will pull up a nicely formatted, current manpage. I haven't found a corresponding web page for Debian or Mandrake.
Anyway, my point is that there is just as much free doc around for Linux as for BSD. And the license of the software really has nothing to do with the documentation. Text should use different licenses, anyway.
Slashdot Mirror
> I have a palm V which I've had for maybe 18 months, as you say using and charging it every day.
I don't want to have to charge it every day.
How long will a full charge last you? A couple of days of use? If it reliably lasts a week of heavy use, then maybe it would be servicable for what I want. Still, I like the ability to roam with my palm, and not have to worry about where to plug it in at night. That is why I chose my IIIe over the V. AAA's last months, and can be purchased cheaply anywhere I'm likely to go. And for the case where I can't buy AAA's (say...camping), I can pack an extra pair in less room than a charger would take, and again I won't need a plug.
To me, the only downside of using AAA's is that it makes for a thicker Palm. I wish someone would up and define a new thin, flat battery standard so that I could still use alkaline's in something thinner than a AAA.
As for the new palms...I'm glad they are moving to USB, but I'm a bit suspicious of this new port. I would appreciate being able to view big ebooks on my palm, but I resist the move towards copy control. We'll see how open it turns out. They way things are going, I'm not terribly optimistic.
--Lenny
> SMT? Blow it out your ass.
Rather unnecessary, don't you think? I don't think you would be quite so hostile to SMT if you had a better understanding of it.
Time to do some informing...
> Surely this 'virtual-multi-CPU' system can only decrease the sheer number of operations per second a CPU of a given size/speed can do?
This statement doesn't make much sense. I think you mean that a CPU which spent the die area on additional functional units as opposed to SMT support could achieve a greater MIPS value. This is true, but only for theoretical MIPS. Simply adding more functional units to modern chips, would *not* improve actual performance. Explanation follows...
> The overhead - whether it be in sacrificed MIPS or die area, of distributing instructions among execution units is going to be significant, compared to a maxed-out single core design.
So you are stating that implementing SMT comes at a cost in die area? Of course it does, but the important point is that using that die area instead to add more conventional execution units would *not* increase the performance of the processor. Why, you ask? There is a limited amount of instruction level parallelism available in a single thread of program execution. Current wide-issue superscalars get something on the order of 2.3 dispatches per clock, despite the fact that they have the *capability* to issue far more. The processor simply can not find enough independent instructions to keep it's functional units full. If memory serves, the Athlon is a 9-issue core. You could add functional units up to 12-issue or more, but your actual dispatch rate would still be around 2-3 per clock. While your theoretical performance would increase your actual performance would remain stagnant.
So, current software does not exhibit enough parallelism to keep the functional units in even current processors busy. SMT proposes to increase available parallelism by issuing instructions from *multiple* threads at once. Instructions from different threads are guaranteed to be independent, so if you have n threads running at once, your number of available instructions for dispatch each clock is improved about n times. Of course, this method has a cost in complexity and area -- now the CPU has to have knowledge of threads, and keep a process table on die. However, provided many threads are run at once, this *greatly* increases the utilization of the processor's resources, and thus the performance of the part.
> Since reading and writing to various RAM caches are the biggest bottlenecks in the current PC architecture, adding more units is just going to lead to increased contention for these resources.
...this is a valid point. SMT particularly increases the burden on instruction fetch and cache, since it is pulling from several different streams at once. However, there are methods that can somewhat compensate for the contention of resources introduced. Now, you have multiple threads available at all times. So, when one thread stalls on a cache miss, the processor can dispatch a different thread to run while the cache miss on the first is being serviced. This effectively hides the latency of the cache miss since the processor is able to do useful work during the service. You see, it's all about keeping those functional units busy.
> So many CPU cycles are wasted with the current generation of software that it seems a bit pointless increasing the number of potential instructions you could perform..
If you believe this, then you should be pro-SMT. SMT doesn't address increasing potential instructions performed per second. Instead, it is an attempt to close the gap between *actual* performance and *theoretical* performance by keeping more of your processor busy.
>you have to question the thinking behind such a modification.
The FHS (Filesystem Hierarchy Standard) lays out the basic organization of a compliant filesystem. The differences between flavors of init scripts run deeper than simply where the scripts are located within the filesystem. Thus, runlevels are beyond the scope of the FHS.
While inappropriate for the FHS, runlevels may well be treated in the more comprehensive LSB. I am unaware if this is on the agenda of the LSB, but the current discrepancy between systems is certainly an annoyance. However, standardization of start up scripts may prove difficult as it involves treading through a few holy wars. Some of the old SysV / BSD schism carries on in the Linux camps, and this partially explains the different runlevel schemes in use today.
Personally, I think rc scripts *should* be homogenized, and the LSB may be the appropriate body to push this through. I don't think the current divide is buying us much other than headaches. However, presently the LSB seems more concerned with binary compatibility at the application level: glibc versioning, ABI standardization, etc. This is a rather important topic as third party companies begin porting to "Linux", which they quickly find is segmented into ~5 pretty much compatible systems. This isn't such a big deal if you have source code, but can be a big hair mess for binary-only applications. Of course, some would argue that they don't *want* binary only applications on their system, but I'll leave that debate to the Slashdot masses...
--Lenny
Mine was one of the "Caviar" 1.6 GB drive, although I don't remember the model number. Yes...quite old.
l
A quick google search pointed me toward the Linux UDMA how-to.
http://www.linux.com/howto/mini/Ultra-DMA-9.htm
The blacklist:
*Western Digital WDC AC11000H, AC22100H, AC32500H, AC33100H, AC31600H - all versions
*Western Digital WDC AC32100H revision 24.09P07
*Western Digital WDC AC23200L revision 21.10N21
...note that this is the *entire* blacklist. It seems that the other drive vendors have their acts together.
Keep in mind that these drives should run just fine as long as you *don't* enable UDMA. I was unaware of this, and that's why I got bit. Also, I'm not sure how up to date or comprehensive the list is, but atleast it provides a place to start.
Happy hacking...
--Lenny
Having a WD drive bit me pretty bad about a year ago. A week or so after a kernel recompile, I wound up with filesystem corruption, even though I was running a stable kernel. I take my computer very seriously, and though I was able to recover my important data, losing the filesystem hurt *bad*.
My faith in Linux took a big hit after that. The only explanations for that error were 1) hardware failure (seemed unlikely) or 2) serious kernel bug. I contemplated migrating to FreeBSD, but was informed that much of the IDE code between Linux and BSD is shared, so any fundamental bug would probably follow me to the new platform. So, I just rebuilt my system and carried on.
A few months later I was reading Kernel Traffic, and someone posted a filesystem corruption problem with the exact same symptoms, using the exact same WD hard drive. One of the hackers identified the source of the problem -- it was Western Digital.
Some models of WD drives are advertised as "UDMA compatible". That is, you can enable UDMA and they will run. However, WD is sidestepping the fact that the drives are *not* UDMA "compliant". Apparently a part of the UDMA spec is the transmission of periodic CRC checks to detect and correct errors. Some WD drives will operate in this mode, but blow off the CRC checks. This is suicidal. If the drive is used in UDMA mode (which it claims compatibility with) you *will* get data corruption...it's just a matter of when and how bad.
Thinking back before the failure, sure enough, I had enabled UDMA in the kernel, looking for a speedup from my UDMA "compatible" drive. WD had mislead me in the features of that drive, and it resulted in data loss. I view this as highly irresponsible on their part, and I will certainly not buy from them again.
--Lenny
One of Sun's headlines is "SUN SHATTERS INDUSTRY PRICE BARRIER WITH FIRST 64-BIT WORKSTATION AT $995". You'll note they are touting the "64-bit" buzzword as much as possible before the new Intel and AMD designs comes out.
But even discounting the new designs from the x86 houses, haven't there been inexpensive Alpha platforms? I know the Multia was supposed to fill a similar role. They are quite dated now, but I expect at the time of their sale, their price tags were around $1K. Alpha's are definitely 64-bit.
Can't you just smell the fear Sun coming off of Sun. Free Unices on commodity hardware is making their offerings look worse and worse. This new product line strikes me as a last-ditch attempt to lay ownership to the low-end workstation market before Linux does...and before commodity processors can claim "64 bit" as well. Many would say it is already too late. Linux has built up prestige now, it just needs a company with a solid rep (say...IBM) selling support to fully displace the older Unices. BSD could pull the same stunt.
If Sun wasn't so protective of Solaris and the high margins that proprietary systems allow, they might see Linux as an opportunity. By embracing Linux now while they still have a good name, they could become *the* Linux company in the coming years. If they stick to their current model, and don't pick up Linux (or do it too late), I can't see them remaining relevant. The Unix landscape has just changed too much.
Interesting times.
--Lenny
You are correct that Republicans are, in a very generic sense, "pro-business". Of course, Democrats are as well, these days, so that doesn't say a whole lot. For all the stomping, and hand-waving, I see virtually no difference between the two major American parties.
But this statement:
> I imagine the smary nerdiness of GAtes will probably annoy good old boy Dubya
...is unfounded, and ridiculuous. Bush went on record during the election as siding with the MS in the DOJ case. He stated that if he won the election, he would do whatever was necessary to "protect companies' right to innovate", or whatever the line from Redmond was at the time. I was aghast.
Still, I'm not too worried. Much as I dislike MS, I've never much believed in the court case. MS is guilty as sin, but I don't think a court decision could ever remedy that. Eventually, MS will choke on its own vomit. The day will come when consumers realize how much MS is toying with them, and slowly they'll drift away.
Besides, I think the OS is rapidly losing the limelight as far as computing goes. I agree with Cringely that MS has peaked and that this new decade will be the decade of Cisco. If I had money lieing around, I'd be buying Cisco stock...
--Lenny, musing on a Sunday morning.
> People always seem to forget that if there is other life out there, that it'd most likely be *completely* different from us.
I agree. I think a lot of the populace is poisoned by Star Trek, where aliens are, by and large, humans with face paint. There is no reason to expect extra-terrestrial life to resemble us.
> To the point that most likely the biggest challenge in finding other life in the universe will be recognizing it as life.
That's ridiculous. We know *exactly* what life is, and how to recognize it. How, you ask? It's quite simple...humans *invented* life. "Life" is merely a concept and a word. It is a notion that humans invented to suite our own needs.
There is a precise scientific definition of what constitutes "life"...we define something as "living" if it meets the 7 (or so) requirements accepted by the scientific community. For a while there was a debate among scientists whether the definition should be changed to include viruses. Last I heard, viruses only met 5 of the 7 points. Hence, they are not technically living creatures. No problem there...life means whatever humans want it to mean. It's just that some humans felt "life" would be a more *useful* category if it included viruses. I see their argument.
Anyway, my point is that many people don't understand that "life" is an entirely human creation -- purely an aspect of human language and science. There is no universal notion of living things. It's just a useful category that humans have created. If we encountered an alien species, there is no guarantee that they would have a similar notion to "life".
--Lenny
It's been a really long time since I've seen one of those...
There was an old joke in the industry that TI had grade A engineering and grade D marketing. They had all sorts of good products that no one used, and they suffered as a result. I think a lot of their lifeblood came from their early patents, which they gladly licensed to other companies.
Of course that was the old TI. Recently they've totally recast themselves as a DSP company. They sold off product lines in most of their old markets, and focused on what they saw as an emerging market with the potential to be huge. It was a bold move, and it seems to have paid off for them. TI is doing pretty well these days, and it looks like they were right about the DSP market.
Live and learn.
--Lenny
a few years ago at (I believe it was) Linuxworld. In an effort to finally settle the age old debate, there was a paintball battle between Team Emacs and Team vi. O'Reilly supplied team shirts, with the respective book covers on the front. There was a fair amount of trash talk on Slashdot before the event. Mind you, these were the early days of Slashdot, and most readers had actually used both.
The match went to Team vi. It is worth noting that they fielded a larger team. To this day, I feel guilty about not attending that conference -- it's quite obvious that Team Emacs needed me.
Ah...the earl(ier) days of Linux.
Lenny
Congrats...one of the best old-style trolls I've read on Slashdot in a long time. :) I wonder how many folks will bite...
Atleast, I sure hope this is a troll. It *is* curious that it should come from such a high user ID. But, surely with a line like "resource-hog abominations on us like KDE, Gnome and TWM" it is. Exploiting the fact that newbies probably don't know about TWM, methinks? Nice touch.
Anyone want to start betting on how many angry replies this generates?
--Lenny
> you know according to linus' our words a large patch like ReiserFS shouldn't have made it in.
...except that he had stated earlier that ReiserFS was on the slate for 2.4.1 . So, there is a bit of a discrepancy there, but given that the ReiserFS statement was specfic and the 2.4.1 statement was general, it seems reasonable to trust the specific.
Of course, treating Linus's quotes as gospel is a bit silly, anyway. Believe it or no, it *is* possible for Fearless Leader to make self-contradictory statements, and he has certainly gone back on his own statements before.
> Another thing is that apparently 2.4 was failing to boot on i386 machines. It had something to do with the CPU's cache not being large enough i belive.
This issue has been tracked down. Of note is the fact that it affects only a very small subset of 386's. If I recall correctly from Kernel Traffic, there was a recall on those early 386's anyway.
--Lenny
I've got a somewhat similar story, actually. I randomly met Larry Ewing recently. For those new to the Linux world, this is that guy that, among other things, drew THE Linux penguin that you still see pasted all over the web. The conversation went something like this...
:)
Me: "So, you do a lot in the Linux world?"
Him: "Well, you know that penguin? I was the one who drew it."
Me: "Oh, you're Larry Ewing."
Him: "That's right."
Me: "Dude, that penguin is *way* over used."
Him: *shrugs*
...I kinda felt bad afterwards, because he seems like a nice guy. I *was* pretty jazzed to meet a "name" in the Linux world. And it's not his fault that his art is overused. Still, I just had to say it.
--Lenny
> Seems to me that it'd be pretty cool to write to the native Crusoe architecture rather than going through the x86 ``emulation''. Does anyone know if it's even possible to bypass the emulation at all, and write native machine code
Just about every Crusoe posts comes standard with one or two of these questions. Actually, I don't know the answer, but I expect it is *not* possible to write to the "native" ISA of the Crusoe chips. In so doing, you would be circumventing important architectural features of the chip, which operate in their ultra-low-level ISA emulation software.
But most importantly, even if you could, they do not *want* you to. Their code-morphing software also performs some optimizations, which would be thrown out the window if you went "native". More importantly, though, native could would be irrevocably tied to *that implementation* of the Crusoe. Transmeta is under no obligation to build the next Crusoe with the same ISA, and probably won't. Since they are emulating another ISA, the physical architecture is only seen by their software, thus they can tweak the architecture as much as they like between revs without having to worry about breaking binary compatibility. As any design engineer knows, this is a Thing of Beauty, and a luxury no other company is allowed. If people started programming native, they would lose that luxury.
So, while writing straight to the Crusoe silicon (if possible) may be fun as a hack, it would not result in maintainable software. Moreover, it is in Transmeta's best interests to discourage such behavior
--Lenny
> This story does clearly not flatter to RMS, who showed us again his desire to GNUlize anything out there, so that he, personally RMS, will be remembered as the one who created a great project(tm).
Mmm...flame bait on a Saturday morning. You know, Slashdot really *was* nicer in the old days when it wasn't fashionable to bash RMS at every turn and drone on with "what's the use?" anytime *any* new tech is announced. Ahem...
What is your evidence that RMS is trying to GNUlize things? The tired Linux GNU/Linux argument? RMS has explained his position on that quite clearly. If people never hear about GNU, then they are not going to hear about software freedoms. Open Source is nice and all that, but RMS is trying to educate users to value their freedom. The "Linux" movement is not trying to do that. So, people could be using Linux and GNU and have no idea *why* the system was constructed and *what* it represents. RMS and others would like to ensure that doesn't happen.
I don't think that RMS is seeking personal attention. I think he just tries to publicize GNU. Presumably, he thinks GNU is important since he has made it his Life's Work. RMS isn't the most diplomatic character, but I greatly respect the GNU project, both on a technical and philosophical level.
--Lenny
> The one thing I want to see between now and 2.6/3.0 is ReiserFS replacing ext2
It sounds likely that ReiserFS will make it into the kernel sometime 2.4.x, perhaps early in the lifecycle. And once one journalling filesystem goes in, the rest will come rather quickly. Quite a bit of the difficulty has been in introducing journalling features into the VFS layer. This is code that will be reused for every journalling-style filesystem implemented.
Also, once ReiserFS becomes stable, it will not necessarily replace ext2fs. I expect ext2 will be around for quite some time, and will remain the default on installs for some time.
--Lenny
Every time you encounter an employee from one of these companies (IBM, Intel, Matsushita, Toshiba), spit on him. When he flies into a rage and demands an explanation, tell him that his company is trying to enslave consumers everywhere. Pretty soon, no one will work for these companies.
...I'm not sure whether or not I'm kidding.
--Lenny
You know, I used to follow Berlin. I was hopeful that it might provide the replacement for X within my professional lifetime. I have since given up hope.
Berlin development is moving at a snail's place. They don't have just a whole lot of people working on it, and I'm not sure they have *anyone* working on it full time. While the attempt is certainly noble, I don't think it's going anywhere.
More importantly, even if they manage to finish the project and come out with a reasonable, clean replacement for X, how are they going to persuade the industry to use it? There is a ridiculous amount of code written for X. To make any inroads they are going to have to have backwards compatibility with X, in which case they've moved to a new house, but carried the old baggage with them.
I certainly do not believe the commercial Unix vendors are going to embrace such a new development. Would the free Unix distros be confident enough to break compatibility and go their own way? I don't see the balance of power between open / commercial shifting that quickly. And so far I have seen zero support of Berlin from any commercial entities (even companies like Red Hat).
If Berlin is used, I expect it will be in "fringe" applications first, not mainline workstations. Particularly, embedded applications might pick it up. They have a much smaller pool of software to tote around, and would probably be happy to have a graphics system nicer, and hopefully smaller, than X.
To bring this to a close, as "cool" as Berlin's feature sheet may sound, the software is far from complete, is advancing slowly, and will face serious obstacles once it *is* complete. I, personally, have given up hope on Berlin. I do not think it will replace X. My hopes lie instead with XFree86. There is much that can be done in the way of gradually extending X, and deprecating old features. Over time, they can drift X towards a cleaner system, relegating cruft to libraries which get loaded less and less often. This is less inspiring, but probably more feasible.
Three reorganizations are worth one revolution.
--Lenny
He didn't forget ssh. Putty is a ssh client for Windows. It's pretty bare bones, but I use it when I'm stuck in Windows.
--Lenny
> Oh my dear, sweet, un-informed friend:
Um...I am well aware that Duke ripped off Army Of Darkness. That was the point of my post.
Thank you.
--Lenny
...but the first go round they called it "Duke Nukem 3D".
Hail to the King.
--Lenny
The BSD's don't necessarily share code, even on simple packages like "ls". They all have their own package, and while it may be true that they steal back and forth, there is certainly a lot of duplicated effort. In the case of OpenBSD, they want their own versions for a simple reason -- they audited them, and they trust them. But for the other BSD's, there isn't a particularly good reason for the redundency.
Recently I was listening to a recording of a table discussion at some BSD conference. One guy brought up this very point: how in the Linux world, all the distros send bugfixes to a single maintainer -- GNU for tar, Apache for httpd, or whatever. That way, it was easier for all distros to receive the benefit. Debian / Red Hat / whatever all just use the same code. (within bounds, of course).
Before this guy even finished his point, 3-4 other guys on the panel jumped on him, practically shouting. It was quite clear that they didn't like the idea of common packages one bit. I didn't even hear any arguments, they just 1) wouldn't consider cooperating like that 2) didn't like being compared to Linux.
No justification provided: those guys were just being close-minded and vicious. I lost a lot of respect for the BSD's right there.
--Lenny
>I usually compile both XFree 4.0 and the kernel with -O6 (and with -fexpensive-optimizations) using GCC version 2.95.2, and havent had any problems at all so far.
The above poster was compiling with pgcc, which optimizes very aggressively, periodically breaking code. In the general case, I would not call pgcc a very usable compiler. It is *definitely* not meant to compile the Linux kernel. For particular purposes, it may be worth using, but I think a lot of the performance gap between gcc and pgcc has been closed in recent releases.
And, if I recall, gcc treats all -O values above 3 the same. So, -O6 will produce the same code as -O3. Actually, that may have changed since egcs remerged, but if so I haven't heard about it...
--Lenny
>Remember the wise words of RMS:
Free software has not to be free as in free beer.
Ah, but OpenBSD, like all BSD's, is *not* free software. The licensing is (surprise, surprise) BSD-style, which qualifies as open source, but not as free software in the notion defined by RMS / GNU / FSF.
Stallmanism aside, I greatly respect OpenBSD as a project and I agree wholeheartedly that it should be supported.
I think I'll buy a T-shirt rather than a CD, though...
--Lenny
I'm shocked at how many people don't know about GNU's online manuals. I find them extremely helpful, and use them routinely.
Also, there are gobs of docs for general Unix/Linux apps, in varying states of update, of course. Check linuxdoc.org for some pointers.
As for documentation for an entire *system* all at once, I know of no good source for generic linux distros. The BSD's have a bit of a leg up there, because they control the entire distribution, rather than a few components.
Or maybe not...I recently pulled up Debian's online user guide, and it is really quite helpful, even if terse. I'd put it about on par with FreeBSD's user guide. The one thing about BSD doc that I envy, though, is the online manpages. Somewhere on FreeBSD's site you can do a query on any FreeBSD command, and it will pull up a nicely formatted, current manpage. I haven't found a corresponding web page for Debian or Mandrake.
Anyway, my point is that there is just as much free doc around for Linux as for BSD. And the license of the software really has nothing to do with the documentation. Text should use different licenses, anyway.
--Lenny