What works best depends on how grody the guts ar to start with, and what all they consist of. It's actually easiest to deal with pure electronics, since they can withstand some things that mechanical parts often can't.
Generally, try to knock as much of the big crud off as you can first, either by brushing or vacuuming. You might want to check for CMOS componentry before you start and if there's ay, be careful about static electricity. (Search the net for how.) We just remodeled out house, and I've vacuumed out the computer twice now and it's working fine - the keyboard is toast, though, which was a real surprise to me. (Ceramic tile dust is really abasive, and when you rip out old tile, it gets *everywhere*!)
If that doesn't do the trick, the best thing to follow up with is a cleaner like Freon TF. Freon is perfect, but the enviros have made it quite difficult to get anymore. The nicest thing about it is that it's so inert it really won't hurt anything, even delicate plastics, and it leaves no residue - like I said, it's about perfect. Freon TF is a strong degreaser, though, so if you apply it to any mechanical parts, they'll likely need lubing afterwards.
If you can't get Freon, then you can use either other solvents/degreasers like chlorothene (ok for most circuit boards as long as they don't swim in it, but it attacks most plastics, so be careful.) I've also used mineral oil in some cases - it's inert, non-conductive, and safe for all the plastics I've tried, but leaves a residue that could require degreasing. I have successfully used a sequence of mineral oil followed by GoJo hand cleaner to degrease and a distilled water rinse on severely dusty oil-soaked stuff.
Another alternative if you really need to scrub off the crud is just plain *distilled* water. Make sure it's distilled, not just filtered, since you don't want any mineral salts left behind causing you problems. I've successfully cleaned up lots of electronics with this method (including my Palm Pilot and cellphone) - just make sure everything is thoroughly dry before firing it up again. Oh, and don't try to speed up the process by drying it in a microwave oven... [grin]
Obviously, any of the above advice may be bad or wrong in your particular situation, so use your best judgement. Reserve extreme measures for extreme cases, and good luck. Almost anything is cleanable if you're careful.
Open source can be more trusted than closed source. Formally designed and reviewed software can be more trusted than chaotically assembled software. These seem orthogonal to me...
In fact, the two are orthogonal to one another in most aspects, but they can be aligned. I don't see any dichotomy between open source and the kind of intense process that produces trusted systems, it's just that the open source movement hasn't matured to that level yet.
Spafford's observation is correct today, but he makes the erroneous assumption that open source community will continue its current practices of doing inadequate planning and testing to ensure real trusted systems. This is one of those areas where the arrival of the commercial backers of open source, like IBM, an offer substantial contributions.
The one thing that has marked the open source movement from the beginning is the ability to respond and change quickly to get the job done. We are in the adolescence of the open source movement, and since trusted systems do require more process than the standard open source method provides, and since people will want trusted open source systems, it's only reasonable to assume that the open source process will morph as required to "scratch the itch"
While it's true that the patent predates the work of the great Tim (shades of Monty Python), it certainly does NOT predate the work of Ted Nelson, the generally acknowledged "inventor" of the hyperlink concept. (Although Nelson himself gives a great deal of credit to Vannevar Bush's pioneering 1930's article "As We May Think", which is likely the first reasonably complete description of these concepts.)
Nelson's original concept and the coining of the terms "hyperlink" and "hypermedia" are all contained in a paper presented at an ACM conference in 1965! (I tried to read it at the time, but I had a hard time following it since I was only three... [grin])
Nelson had implementations of the Xanadu hypertext concept running in FORTRAN in the early '70s IIRC.
Regardless of anyone's claims, it looks quite easy to show prior art should anyone attempt to press any patent claim on hyperlinks.
I usually refrain from ad hominem attacks, but in this case, it was warranted - the guy clearly was talking without knowing his subject. It's fair to call him on that, and to point out those factual errors for the rest of the community.
Despite your worries that I'm a latcomer "IT boss", my slashdot ID is about 130,000 lower than yours, and I was a participant here for several years before I bothered to register at the advent of moderation. What *I've* seen Slashdot becoming over that time is a community that is increasingly populated by clueless newbies shooting their mouths off and a signal to noise ratio approaching zero. And yes, sometimes that ticks me off.
My comments weren't intended to be arrogant (sorry if that's what came across), but simply to inject some factual basis into the discussion where little existed previously. The reason I bothered to do this is that I've seen such little things lead to big misconceptions among the community in the past. I would hope that we all recognize that experience is the best teacher and those that have experience doing something can ofer a lot to those of us that haven't.
I never said I was an expert on IBM's LVM, in fact, I haven't used it since 1994-ish. I have a fair amount of experience doinf these things, though, using half a dozen LVM systems, including Veritas Volume Manager and Sun's Solstice Disk Suite.
The whole point of LVM is to put more than one disk in a VG, so I don't get your comment at all. That *would* explain your problems with JFS, though, since any disk failure is guaranteed to take out your log volume!
If properly configured, all of these things work, and work well. That's why people use them!
This is all about money, not science. Sure, the radio astronomers would like to have all the high-end frequencies, and probably will for a number of years, but the band they got in this deal is low enough that it could easily be commercially usable in several years.
At that point, it'll be worth countless billions, and you can bet they'll be trying to shake down the ".rad's" in excahnge for "giving up" their RF turf. This is *very* bad for the future of always-on, always available high-speed wireless networking and it's a horrible deal for everyone but the astronomers. It's not a problem now because those frequencies are not yet commercially viable - but they *will* be.
(I used Motorola's 18 GHz LAN back in the early 90's. Other than sub-optimal wall penetration, these high frequencies work well - and more importantly, there's a *TON* of bandwidth up there, and as Shannon taught us, you can trade bandwidth for power.)
Oh, gad, let's hope not. SMIT is great for those illiterate in Unix, and a nightmare for the literati. (Although it's "show me the command line of how you'd do this" option can be a good leaning tool for admins.)
I remember way back in the early AIX days discovering the hard way that S*IT didn't keep it's state in the config files, but in the ODB, so any changes you made by hand would be silently undone when S*IT realized the config file didn't match the ODB, forcing you to do nearly everything through S*IT if you wanted the changes to stick. AAAARGH!
Your objections don't even make sense, and it's clear you've never worked with enterprise environments:
LVs complicate system management; in particular, they make it more difficult to figure out what physical devices a file system actually depends on, and they make it much more likely that you make a mistake when setting up disks.
Not really, the LVM is always happy to tell you what maps to what, and this is not problem unless you create a logical root volume in which case you deserve what you get. Disks are too cheap these days for that sort of foolishness, and if you need LVM you can afford it.
LVs break the correspondence between block numbers and head positions. With simple physical mappings, small differences in block numbers usually correspond to small head movements, something file system designs tend to rely on, but with LVs, all bets are off.
What planet have you been living on, Mr. Jetson? The geometry the OS sees has had little or no relation to the physical geometry of the disk since disk controllers became more intelligent than the first PCs several years ago. Where things will actually land physically on modern disks has been totally out of your control for years, which is the reason Sun dropped the ability to twiddle cylinder groups way back in the move from SunOS to Solaris.
If you take advantage of LVs spanning multiple disks, you just multiplied your risk of data loss, because if any one of those disks goes, so does the whole file system.
That's why LVMs and RAID travel in packs - they form a symbiotic realtionship. With disks as cheap as they are, mnay people just use 0+1 (mirroring and striping), which eliminates this concern. If you're cheap and don't mind abysmal performance in degraded mode, you can go with 5.
If you need file systems bigger than a single disk, use RAID.
Have you ever done this? RAID tools that do this are inherently *doing* LVM, even if they're not calling it that and it's not a separate tool. RAID per se typically handles Mirroring, Striping and Parity, the volume manager handles concatenation. These are often merged in a single tool, but concatenation of disks is not strictly speaking a RAID function.
GNU Parted and PartitionMagic already provide you with the ability to resize partitions without a full backup and restore; you don't need LVMs for that.
While decent, these are hardly enterprise-class tools. I also sincerely doubt that either is capable of resizing volumes that span physical disks, since that *does* imply LVM functionality, unless there's an LVM hiding under the covers and lying to these tools. There are people that have a real need for single files that are tens or hundreds of gigabytes, so *not* spanning disks isn't really an option.
One of these days, Linux may get concatenated mounts, which would give you another, very reliable and simple way of having file systems span multiple disks. Adding concatenated mounts would probably not be any harder than hacking in an LVM.
I'll confess to being ignorant of concatenated mounts (although I asume this would allow simply allow concatenation at mount time, but LVMs have significant benefits, and the people who need them have been using them quite successfully for years. There's certainly noting that's going to prevent the need for them in the near term. LVMs make "big computing" possible on small computers. There's just no effective way around that.
LVMs may have thier shortcomings, and they aren't appropriate everywhere. Most people won't need them, and the ones that do can handle the minimal incremental complexity. Further, what are often called LVMs are usually today also RAID and JFS tools. This sort of capabilty is not easily duplicated in other ways or we'd have been doing it already for years.
It seems you really are living in Jetson-land as your ID indicates if you think things like "object based disk storage systems" are going to have large-scale real-world impacts anytime soon. Ah, the naivete of youth...
Re:Mattel and the Learning Company are screwed up
on
Mattel Spyware
·
· Score: 3
I have a good friend who worked at the Learning Company for quite some time, and he told me no end of horror stories about an utter disregard for engineering quality, lack of concern for usability, maintainability of code or anything that sounded remotely like common sense. They'd basically just ship all their applications when they could get them to more or less run and not when they were running reliability.[sic]
And this somehow distinguishes them from the rest of the sofware industry? Not a chance. Check out Mark Minasi's http://www.softwareconspiracy.com/ book for more info, but the dirty "secret" of the software industry is that darn near all software development is done like that today. It shouldn't be, but it is. I've seen enough to know - the hardware mfrs are even worse...
FYI - the IEEE standard that describes Sun's OpenBoot PROM interface is IEEE 1275. You can find the info on it the "Open Firmware Home Page" at http://playground.sun.com/1275/home.html
Although it looks like it's been untouched since early 1999, it also appears quite a bit was done with it for the PowerPC platforms, and it could certainly be used on pretty much any other platform as well, if it makes sense. It may be time to revive this IEEE committee to jump-start both it and the efforts to produce viable open BIOS implementations.
Re:Legacy-free PC? Microsoft?
on
Linux BIOS
·
· Score: 2
All that baggage is even more painful for them then it is for the rest of us, because they're the ones that gt shouted at when things don't work. Microsoft does indeed want the BIOS to become a thing of the past. Count on it.
(Maybe this was part of IBM's plan all along? Yeah, right...)
Your sizeand speed arguments are wrong. From both a computational and memory point-of-view, X is *much* lighter than Windows. How do I know? I run Linux and X on several machines at home that are not capable of running Windows 95: one is a 486SX/33 and another is a 16MB Toshiba Libretto 50J. Both of these run X fine but wouldn't stand a ghost of a chance running 95, much less 98 or newer.
The real memory hog is the window manager - go back to slim WM's like twm or fvwm and you'l be surprised how much you can do with very little CPU and memory. If you want something piggish like GNOME or even KDE, though, all bets are off, but that's NOT the fault of X!
As for stability, xfree isn't quite up there with commercial X implementations (one of the reasons people still willingly pay $$ for Suns), but it'spretty good and getting better.
As I've noted several times lately, the biggest reason X needs overhaul or replacement is multimedia: support for motion video and, particularly, audio. In addition, there needs to be some standard way of sharing X displays ala HP's Shared X. (This would let you do cool things like send stereo from your central computer to simple, cheap "X-terminal" devices (which could in fact be headless) in various rooms in your home. Not to mention the cool telephony apps you could do with that sort of capability. This needs to be added or X, and consequently Linux/BSD/Unix will yet lose the war.)
Not really. The Sun (EE)PROM monitor is actually a fully capable FORTH environment, and I saw some pretty cool hacks for it floating around inside Sun (customers are obviously discouraged from hacking the monitor, but at least it's possible on a Sun, unlike most of their competition. This sort of thing is most often used to "fix" the IDPROM/hostid code that plays havoc with old licensed software on new hardware.)
The Sun monitor has even been codified as an IEEE standard, so anyone should be able to implement and use it.
This is damn cool, though. The implications for net-booting embedded devices alone are staggering. This sure beats flashing boot code into the NIC before you can boot, or living in the PXE straightjacket. (We'll know these guys have cojones when this BIOS inludes support for laptop functions like PCCard, ACPI suspend/resume, and hot-docking. These are *really* ugly areas, but breaking DOS compatibility makes things much easier.)
BTW: Microsoft's plan, too, is for the BIOS to go away and be replaced by some simple address tables telling where things are - I think the "legacy-free" PCs (no ISA, serial, or parallel, among other things) may have this sort of BIOS already. This is a good time fo the OpenSource crowd to bend Intel's ear and make sure that Microsoft doesn't dictate NG BIOS standards to the detriment of everyone else. (They enforce compliance with their plans through substantial OS "discounts" for PC9x/WHQL standards compliance, so they're not really optional for the OEMs that need the Windows OS.)
This one clearly doesn't satisfy the desired criteria, but it lets me use a pun I've been dying to use all week:
Feds with autos storm Sieze cow'rin boy in closet It's OrwElian
And yes, cow'rin ("cowering") is legitimately two syllables on the authority of Rrrabbie Burrrns, who probably never wrote a haiku in his life, although apparently, there is a Scottish haikuist(?) of some note.
Good idea. Let's go for serious poetry overloading, though, and give large additional bonuses for haiku that are not only self describing, but include anagrams and palindromes as well.:-)
Further, embedded Carrollian logic puzzles/references, puns, or other forms of wordplay would each double the score. (I'll think about this tonight - I haven't tackled a really clever word puzzle since I unravelled the new answer to "Why is a Raven like a writing desk?"
Of course now we're well beyond anything computers are likely to do in our lifetimes, so this will be a warmware competition to write palindromic, anagrammatic(?!), pun-filled, self-describing haiku riddles. Whoa... dain bramage. (Yeah, Spoonerisms should count, too!)
Or, this could just devolve into something like Finnegan's Wake, which would require artificial insanity rather than (or is that in addition to?) artificial intelligence - the former is probably much more difficult to produce...;-)
Seriously, it would be really fun to see how many of these aspects one can cram into the haiku form, creating true meta-haiku.
You're right, but your comment ignores the fact that the world is changing, and not just amongst geeks:
Cable and xDSL "modems" have brought 10baseT to millions of homes, and the incredible sales (backordered most places) of gadgets like Linksys' little $150 NAT/Firewall/switch/DHCP server box convince me that this is a market that's rapidly maturing. Not to mention that such a camera would plug in transparently to any LAN, providing value to corporatations and SOHO customers.
Seems like a no-brainer to me: Ethernet silicon is at least as cheap as USB silicon, and you get to completely ignore troublesome drivers in the bargain - forever.
Internet standard interfaces have significant value for all kinds of things, not just networked PCs and servers...
Zip disks are a really bad choice for any mobile application. When I worked for Dell, they really resisted selling Zip drives in their laptops for a long time because the non-operating shock limit for a Zip drive is less than the operating shock limit for a floppy. Of course, they eventually decided to sell them anyway - after all, who cares about a few thousand customers when there's money to be had?
Zip drives are unbelievably fragile. This effect is well-known even among desktop Zip drive users as the "click of death" problem, where the head actually comes off the arm, usually destroying the disk in the process. And that's if you're lucky, since you'll only destroy one disk with that failure mode. If you're not lucky, the head doesn't come off, but just gets knocked cockeyed and will then destroy every disk you put in the drive trying to see if you can get it to work. (That said, I use Zip semi-occasionally and have never encountered the problem myself. I'm paranoid about shocking the drive, though, and treat it like a Faberge egg.)
I think Minidiscs are just too expensive and proprietary.
Why are we using disks anymore anyway? Hasn't anyone noticed that you don't need disks anymore when you have a network? Where are the cameras with a built-in FTP/file server and Ethernet, 802.11, or Bluetooth links?
I'd buy an Ethernet camera in a heartbeat - that's far more interoperable than USB is right now, and avoids OS compatibility problems.
Just to add to this comment - most of the "poverty-stricken" in the US are vastly better off than the average citizen in many other countries, and even far better off than the average American over the course of the 20th century. I was given the link above last week, and it was enlightening what the government now considers "poverty"...
I haven't used Opera lately (since I started hosting my bookmarks remotely via Netscape's wonderful roaming feature) but it is small: The last Windows version I tried fit on a floppy disk, and it's really a pretty good basic browser. It lacks some of the frills, but it's both small AND fast. Mozilla has some impressive aspects, but (like the Gnome stuff it is becoming increasingly tied to) it's a pig. I'm leaning toward Konqueror for my routine Linux browser, but I guess I'll have to give this new Opera a try...
Somewhere in a junk box in my garage is an old AT-style keyboard adapter box commonly called a "keyboard wedge". These are still used sometimes to do things like provide input from barcode scanners and the like.
The one I've got has a small 8-bit micro in it that also has the ability to capture and replay keystroke sequences delimited by truly odd and awkward command key sequences. Heck, IIRC, someone even posted something here a while back about a keyboard with a built-in capture and playback buffer. One thing I noticed about the way mine works is that it preserves the timing of the input in order to make sure it doesn't get ahead of the applicaiton. Any such gadget would defeat this scheme.
The biggest problem with retinal scans is public acceptance.
In addition to the fact you mentioned that it's possible to sureptitiously determine a great deal about the user's health and habits (alcohol, drugs, late night web binges, etc.) there's the more formidable problem that most people view the process as unsanitary. I read a paper about this some time back. (In The Lancet??) Bottom line, they noted these perceptions were the primary impediment to retinal IDs, and that people would not accept retinal scans as routine.
Sometimes, though you just have to speak with candor rather than diplomacy. I could have danced around the offense, but wouldn't have made the point as well. If one person tries to use the tools and philosophy of Unix instead of C on thier next project, I'll be happy and the world will be a better place.
There's no panacea. Not scripting, not C, but in general, it makes sense to use the highest-level tool available for a particular task, and modularizing helps mix those tools.
Slashdot Mirror
What works best depends on how grody the guts ar to start with, and what all they consist of. It's actually easiest to deal with pure electronics, since they can withstand some things that mechanical parts often can't.
Generally, try to knock as much of the big crud off as you can first, either by brushing or vacuuming. You might want to check for CMOS componentry before you start and if there's ay, be careful about static electricity. (Search the net for how.) We just remodeled out house, and I've vacuumed out the computer twice now and it's working fine - the keyboard is toast, though, which was a real surprise to me. (Ceramic tile dust is really abasive, and when you rip out old tile, it gets *everywhere*!)
If that doesn't do the trick, the best thing to follow up with is a cleaner like Freon TF. Freon is perfect, but the enviros have made it quite difficult to get anymore. The nicest thing about it is that it's so inert it really won't hurt anything, even delicate plastics, and it leaves no residue - like I said, it's about perfect. Freon TF is a strong degreaser, though, so if you apply it to any mechanical parts, they'll likely need lubing afterwards.
If you can't get Freon, then you can use either other solvents/degreasers like chlorothene (ok for most circuit boards as long as they don't swim in it, but it attacks most plastics, so be careful.) I've also used mineral oil in some cases - it's inert, non-conductive, and safe for all the plastics I've tried, but leaves a residue that could require degreasing. I have successfully used a sequence of mineral oil followed by GoJo hand cleaner to degrease and a distilled water rinse on severely dusty oil-soaked stuff.
Another alternative if you really need to scrub off the crud is just plain *distilled* water. Make sure it's distilled, not just filtered, since you don't want any mineral salts left behind causing you problems. I've successfully cleaned up lots of electronics with this method (including my Palm Pilot and cellphone) - just make sure everything is thoroughly dry before firing it up again. Oh, and don't try to speed up the process by drying it in a microwave oven... [grin]
Obviously, any of the above advice may be bad or wrong in your particular situation, so use your best judgement. Reserve extreme measures for extreme cases, and good luck. Almost anything is cleanable if you're careful.
Open source can be more trusted than closed source. Formally designed and reviewed software can be more trusted than chaotically assembled software. These seem orthogonal to me...
In fact, the two are orthogonal to one another in most aspects, but they can be aligned. I don't see any dichotomy between open source and the kind of intense process that produces trusted systems, it's just that the open source movement hasn't matured to that level yet.
Spafford's observation is correct today, but he makes the erroneous assumption that open source community will continue its current practices of doing inadequate planning and testing to ensure real trusted systems. This is one of those areas where the arrival of the commercial backers of open source, like IBM, an offer substantial contributions.
The one thing that has marked the open source movement from the beginning is the ability to respond and change quickly to get the job done. We are in the adolescence of the open source movement, and since trusted systems do require more process than the standard open source method provides, and since people will want trusted open source systems, it's only reasonable to assume that the open source process will morph as required to "scratch the itch"
While it's true that the patent predates the work of the great Tim (shades of Monty Python), it certainly does NOT predate the work of Ted Nelson, the generally acknowledged "inventor" of the hyperlink concept. (Although Nelson himself gives a great deal of credit to Vannevar Bush's pioneering 1930's article "As We May Think", which is likely the first reasonably complete description of these concepts.)
Nelson's original concept and the coining of the terms "hyperlink" and "hypermedia" are all contained in a paper presented at an ACM conference in 1965! (I tried to read it at the time, but I had a hard time following it since I was only three... [grin])
Nelson had implementations of the Xanadu hypertext concept running in FORTRAN in the early '70s IIRC.
Regardless of anyone's claims, it looks quite easy to show prior art should anyone attempt to press any patent claim on hyperlinks.
I usually refrain from ad hominem attacks, but in this case, it was warranted - the guy clearly was talking without knowing his subject. It's fair to call him on that, and to point out those factual errors for the rest of the community.
Despite your worries that I'm a latcomer "IT boss", my slashdot ID is about 130,000 lower than yours, and I was a participant here for several years before I bothered to register at the advent of moderation. What *I've* seen Slashdot becoming over that time is a community that is increasingly populated by clueless newbies shooting their mouths off and a signal to noise ratio approaching zero. And yes, sometimes that ticks me off.
My comments weren't intended to be arrogant (sorry if that's what came across), but simply to inject some factual basis into the discussion where little existed previously. The reason I bothered to do this is that I've seen such little things lead to big misconceptions among the community in the past. I would hope that we all recognize that experience is the best teacher and those that have experience doing something can ofer a lot to those of us that haven't.
I never said I was an expert on IBM's LVM, in fact, I haven't used it since 1994-ish. I have a fair amount of experience doinf these things, though, using half a dozen LVM systems, including Veritas Volume Manager and Sun's Solstice Disk Suite.
The whole point of LVM is to put more than one disk in a VG, so I don't get your comment at all. That *would* explain your problems with JFS, though, since any disk failure is guaranteed to take out your log volume!
If properly configured, all of these things work, and work well. That's why people use them!
This is all about money, not science. Sure, the radio astronomers would like to have all the high-end frequencies, and probably will for a number of years, but the band they got in this deal is low enough that it could easily be commercially usable in several years.
At that point, it'll be worth countless billions, and you can bet they'll be trying to shake down the ".rad's" in excahnge for "giving up" their RF turf. This is *very* bad for the future of always-on, always available high-speed wireless networking and it's a horrible deal for everyone but the astronomers. It's not a problem now because those frequencies are not yet commercially viable - but they *will* be.
(I used Motorola's 18 GHz LAN back in the early 90's. Other than sub-optimal wall penetration, these high frequencies work well - and more importantly, there's a *TON* of bandwidth up there, and as Shannon taught us, you can trade bandwidth for power.)
Oh, gad, let's hope not. SMIT is great for those illiterate in Unix, and a nightmare for the literati. (Although it's "show me the command line of how you'd do this" option can be a good leaning tool for admins.)
I remember way back in the early AIX days discovering the hard way that S*IT didn't keep it's state in the config files, but in the ODB, so any changes you made by hand would be silently undone when S*IT realized the config file didn't match the ODB, forcing you to do nearly everything through S*IT if you wanted the changes to stick. AAAARGH!
Your objections don't even make sense, and it's clear you've never worked with enterprise environments:
LVs complicate system management; in particular, they make it more difficult to figure out what physical devices a file system actually depends on, and they make it much more likely that you make a mistake when setting up disks.
Not really, the LVM is always happy to tell you what maps to what, and this is not problem unless you create a logical root volume in which case you deserve what you get. Disks are too cheap these days for that sort of foolishness, and if you need LVM you can afford it.
LVs break the correspondence between block numbers and head positions. With simple physical mappings, small differences in block numbers usually correspond to small head movements, something file system designs tend to rely on, but with LVs, all bets are off.
What planet have you been living on, Mr. Jetson? The geometry the OS sees has had little or no relation to the physical geometry of the disk since disk controllers became more intelligent than the first PCs several years ago. Where things will actually land physically on modern disks has been totally out of your control for years, which is the reason Sun dropped the ability to twiddle cylinder groups way back in the move from SunOS to Solaris.
If you take advantage of LVs spanning multiple disks, you just multiplied your risk of data loss, because if any one of those disks goes, so does the whole file system.
That's why LVMs and RAID travel in packs - they form a symbiotic realtionship. With disks as cheap as they are, mnay people just use 0+1 (mirroring and striping), which eliminates this concern. If you're cheap and don't mind abysmal performance in degraded mode, you can go with 5.
If you need file systems bigger than a single disk, use RAID.
Have you ever done this? RAID tools that do this are inherently *doing* LVM, even if they're not calling it that and it's not a separate tool. RAID per se typically handles Mirroring, Striping and Parity, the volume manager handles concatenation. These are often merged in a single tool, but concatenation of disks is not strictly speaking a RAID function.
GNU Parted and PartitionMagic already provide you with the ability to resize partitions without a full backup and restore; you don't need LVMs for that.
While decent, these are hardly enterprise-class tools. I also sincerely doubt that either is capable of resizing volumes that span physical disks, since that *does* imply LVM functionality, unless there's an LVM hiding under the covers and lying to these tools. There are people that have a real need for single files that are tens or hundreds of gigabytes, so *not* spanning disks isn't really an option.
One of these days, Linux may get concatenated mounts, which would give you another, very reliable and simple way of having file systems span multiple disks. Adding concatenated mounts would probably not be any harder than hacking in an LVM.
I'll confess to being ignorant of concatenated mounts (although I asume this would allow simply allow concatenation at mount time, but LVMs have significant benefits, and the people who need them have been using them quite successfully for years. There's certainly noting that's going to prevent the need for them in the near term. LVMs make "big computing" possible on small computers. There's just no effective way around that.
LVMs may have thier shortcomings, and they aren't appropriate everywhere. Most people won't need them, and the ones that do can handle the minimal incremental complexity. Further, what are often called LVMs are usually today also RAID and JFS tools. This sort of capabilty is not easily duplicated in other ways or we'd have been doing it already for years.
It seems you really are living in Jetson-land as your ID indicates if you think things like "object based disk storage systems" are going to have large-scale real-world impacts anytime soon. Ah, the naivete of youth...
I have a good friend who worked at the Learning Company for quite some time, and he told me no end of horror stories about an utter disregard for engineering quality, lack of concern for usability, maintainability of code or anything that sounded remotely like common sense. They'd basically just ship all their applications when they could get them to more or less run and not when they were running reliability.[sic]
And this somehow distinguishes them from the rest of the sofware industry? Not a chance. Check out Mark Minasi's http://www.softwareconspiracy.com/ book for more info, but the dirty "secret" of the software industry is that darn near all software development is done like that today. It shouldn't be, but it is. I've seen enough to know - the hardware mfrs are even worse...
FYI - Microsoft's pages for "Legacy-free" PCs and BIOSes: http://www.microsoft.com/hwdev/newpc/
FYI - the IEEE standard that describes Sun's OpenBoot PROM interface is IEEE 1275. You can find the info on it the "Open Firmware Home Page" at http://playground.sun.com/1275/home.html
Although it looks like it's been untouched since early 1999, it also appears quite a bit was done with it for the PowerPC platforms, and it could certainly be used on pretty much any other platform as well, if it makes sense. It may be time to revive this IEEE committee to jump-start both it and the efforts to produce viable open BIOS implementations.
All that baggage is even more painful for them then it is for the rest of us, because they're the ones that gt shouted at when things don't work. Microsoft does indeed want the BIOS to become a thing of the past. Count on it.
(Maybe this was part of IBM's plan all along? Yeah, right...)
Your sizeand speed arguments are wrong. From both a computational and memory point-of-view, X is *much* lighter than Windows. How do I know? I run Linux and X on several machines at home that are not capable of running Windows 95: one is a 486SX/33 and another is a 16MB Toshiba Libretto 50J. Both of these run X fine but wouldn't stand a ghost of a chance running 95, much less 98 or newer.
The real memory hog is the window manager - go back to slim WM's like twm or fvwm and you'l be surprised how much you can do with very little CPU and memory. If you want something piggish like GNOME or even KDE, though, all bets are off, but that's NOT the fault of X!
As for stability, xfree isn't quite up there with commercial X implementations (one of the reasons people still willingly pay $$ for Suns), but it'spretty good and getting better.
As I've noted several times lately, the biggest reason X needs overhaul or replacement is multimedia: support for motion video and, particularly, audio. In addition, there needs to be some standard way of sharing X displays ala HP's Shared X. (This would let you do cool things like send stereo from your central computer to simple, cheap "X-terminal" devices (which could in fact be headless) in various rooms in your home. Not to mention the cool telephony apps you could do with that sort of capability. This needs to be added or X, and consequently Linux/BSD/Unix will yet lose the war.)
Not really. The Sun (EE)PROM monitor is actually a fully capable FORTH environment, and I saw some pretty cool hacks for it floating around inside Sun (customers are obviously discouraged from hacking the monitor, but at least it's possible on a Sun, unlike most of their competition. This sort of thing is most often used to "fix" the IDPROM/hostid code that plays havoc with old licensed software on new hardware.)
The Sun monitor has even been codified as an IEEE standard, so anyone should be able to implement and use it.
This is damn cool, though. The implications for net-booting embedded devices alone are staggering. This sure beats flashing boot code into the NIC before you can boot, or living in the PXE straightjacket. (We'll know these guys have cojones when this BIOS inludes support for laptop functions like PCCard, ACPI suspend/resume, and hot-docking. These are *really* ugly areas, but breaking DOS compatibility makes things much easier.)
BTW: Microsoft's plan, too, is for the BIOS to go away and be replaced by some simple address tables telling where things are - I think the "legacy-free" PCs (no ISA, serial, or parallel, among other things) may have this sort of BIOS already. This is a good time fo the OpenSource crowd to bend Intel's ear and make sure that Microsoft doesn't dictate NG BIOS standards to the detriment of everyone else. (They enforce compliance with their plans through substantial OS "discounts" for PC9x/WHQL standards compliance, so they're not really optional for the OEMs that need the Windows OS.)
This one clearly doesn't satisfy the desired criteria, but it lets me use a pun I've been dying to use all week:
Feds with autos storm
Sieze cow'rin boy in closet
It's OrwElian
And yes, cow'rin ("cowering") is legitimately two syllables on the authority of Rrrabbie Burrrns, who probably never wrote a haiku in his life, although apparently, there is a Scottish haikuist(?) of some note.
glug, glug, burble, stir
the sound of coffee pouring
Maxwell House morning
Good idea. Let's go for serious poetry overloading, though, and give large additional bonuses for haiku that are not only self describing, but include anagrams and palindromes as well. :-)
;-)
Further, embedded Carrollian logic puzzles/references, puns, or other forms of wordplay would each double the score. (I'll think about this tonight - I haven't tackled a really clever word puzzle since I unravelled the new answer to "Why is a Raven like a writing desk?"
Of course now we're well beyond anything computers are likely to do in our lifetimes, so this will be a warmware competition to write palindromic, anagrammatic(?!), pun-filled, self-describing haiku riddles. Whoa... dain bramage. (Yeah, Spoonerisms should count, too!)
Or, this could just devolve into something like Finnegan's Wake, which would require artificial insanity rather than (or is that in addition to?) artificial intelligence - the former is probably much more difficult to produce...
Seriously, it would be really fun to see how many of these aspects one can cram into the haiku form, creating true meta-haiku.
You're right, but your comment ignores the fact that the world is changing, and not just amongst geeks:
Cable and xDSL "modems" have brought 10baseT to millions of homes, and the incredible sales (backordered most places) of gadgets like Linksys' little $150 NAT/Firewall/switch/DHCP server box convince me that this is a market that's rapidly maturing. Not to mention that such a camera would plug in transparently to any LAN, providing value to corporatations and SOHO customers.
Seems like a no-brainer to me: Ethernet silicon is at least as cheap as USB silicon, and you get to completely ignore troublesome drivers in the bargain - forever.
Internet standard interfaces have significant value for all kinds of things, not just networked PCs and servers...
Zip disks are a really bad choice for any mobile application. When I worked for Dell, they really resisted selling Zip drives in their laptops for a long time because the non-operating shock limit for a Zip drive is less than the operating shock limit for a floppy. Of course, they eventually decided to sell them anyway - after all, who cares about a few thousand customers when there's money to be had?
Zip drives are unbelievably fragile. This effect is well-known even among desktop Zip drive users as the "click of death" problem, where the head actually comes off the arm, usually destroying the disk in the process. And that's if you're lucky, since you'll only destroy one disk with that failure mode. If you're not lucky, the head doesn't come off, but just gets knocked cockeyed and will then destroy every disk you put in the drive trying to see if you can get it to work. (That said, I use Zip semi-occasionally and have never encountered the problem myself. I'm paranoid about shocking the drive, though, and treat it like a Faberge egg.)
I think Minidiscs are just too expensive and proprietary.
Why are we using disks anymore anyway? Hasn't anyone noticed that you don't need disks anymore when you have a network? Where are the cameras with a built-in FTP/file server and Ethernet, 802.11, or Bluetooth links?
I'd buy an Ethernet camera in a heartbeat - that's far more interoperable than USB is right now, and avoids OS compatibility problems.
Just to add to this comment - most of the "poverty-stricken" in the US are vastly better off than the average citizen in many other countries, and even far better off than the average American over the course of the 20th century. I was given the link above last week, and it was enlightening what the government now considers "poverty"...
I haven't used Opera lately (since I started hosting my bookmarks remotely via Netscape's wonderful roaming feature) but it is small: The last Windows version I tried fit on a floppy disk, and it's really a pretty good basic browser. It lacks some of the frills, but it's both small AND fast. Mozilla has some impressive aspects, but (like the Gnome stuff it is becoming increasingly tied to) it's a pig. I'm leaning toward Konqueror for my routine Linux browser, but I guess I'll have to give this new Opera a try...
Somewhere in a junk box in my garage is an old AT-style keyboard adapter box commonly called a "keyboard wedge". These are still used sometimes to do things like provide input from barcode scanners and the like.
The one I've got has a small 8-bit micro in it that also has the ability to capture and replay keystroke sequences delimited by truly odd and awkward command key sequences. Heck, IIRC, someone even posted something here a while back about a keyboard with a built-in capture and playback buffer. One thing I noticed about the way mine works is that it preserves the timing of the input in order to make sure it doesn't get ahead of the applicaiton. Any such gadget would defeat this scheme.
The biggest problem with retinal scans is public acceptance.
In addition to the fact you mentioned that it's possible to sureptitiously determine a great deal about the user's health and habits (alcohol, drugs, late night web binges, etc.) there's the more formidable problem that most people view the process as unsanitary. I read a paper about this some time back. (In The Lancet??) Bottom line, they noted these perceptions were the primary impediment to retinal IDs, and that people would not accept retinal scans as routine.
I'm amazed at the amount of vitriol that little sig is generating. Kind of makes the point about evolution being a religion of its own, I guess...
Me? Plea for peace? Not too often...
Sometimes, though you just have to speak with candor rather than diplomacy. I could have danced around the offense, but wouldn't have made the point as well. If one person tries to use the tools and philosophy of Unix instead of C on thier next project, I'll be happy and the world will be a better place.
There's no panacea. Not scripting, not C, but in general, it makes sense to use the highest-level tool available for a particular task, and modularizing helps mix those tools.