IMHO distros like RedHat and Suse blow chunks, they hold your hand to do everything and almost force GUI usage upon people.
I can't speak for SuSE, but all the GUI tools in RH-alike distros do is modify files under/etc, and especially/etc/sysconfig. Read those files, and the initscripts in/etc/init.d that parse them, and you'll be well-equipped to go hacking them yourself. Sometimes this is even necessary in order to achieve some specialised or otherwise unsupported goal.
Lets take an open source program, which we'll call program X. Program X's developers happily continue adding cool new features and releasing out new versions. The problem is, the only way for GNU/Linux users to get program X is 1) build it from source, or 2) hope someone has built a binary for their distribution. Option #1 is time consuming, and tracking down build dependencies is difficult and error prone. Which leaves us with option #2, the current state of GNU/Linux distributions.
You forgot option 3 - wait for your chosen distro vendor to integrate it into one of their future releases. If this doesn't happen quickly enough for you, consider switching distro. The best way to think of the FOSS world is like a perpetual 'technology preview programme'. This is no different to life in Windows-world or Solaris-world. If I see a neat feature in a beta of Windows Vista, but want it NOW in Windows XP, I either get to work to make it happen (subject to coding prowess, source code availability and licensing restrictions) or wait for Vista to show up on the shelves. I don't see why anyone holds FOSS OSs to a higher standard than any other OS.
If you think waiting for a future distro release isn't the right answer for the majority of non- or less-technical users, and that obtaining good packages is slow and/or difficult, perhaps you should start a business offering a packaging service?
You got it wrong. Dell sells CONSUMER desktop computers. GNU/Linux is not a CONSUMER desktop OS. This just shows that Dell doesn't want to sell to the typical GNU/Linux user.
Dell repersents his customers... the ones he already has. If the Linux community want to sell Linux to Dell and his customers, then they have give Dell (and by extension, his customers) what he wants.
Thing is, the mythical 'Linux community' doesn't exist in the form you seem to think it does. The 'Linux community' just wants to build, use and share useful software. Another, separate group - Dell customers - apparently increasingly want to buy computers with some flavour of GNU/Linux preloaded, and Dell would like a slice of that market. It's therefore up to Dell to find a distro, selection of distros, or roll their own distro that suits the hardware they're shipping, the majority of their target market, and at a cost Dell is prepared to pay. If they don't want to do that (and perhaps it's just not a profitable market for Dell to be in), they'll have to put up with being shut out of that market, and the customers will have to put up with not being able to get a Dell-priced PC with Linux preloaded. Sooner or later, though, one side will buckle, or a competitor to Dell will arrive on the market who is prepared to do the legwork in order to sell such machines.
RPM is a buggy piece of crap that trashes its own database on a regular basis
Your hardware must be flaky. I've been using RH since 2.1 and have never had RPM trash (i.e. lose entirely, lose substantial portions thereof, or be otherwise corrupted so badly as to force a reinstall) my database. I've come close to doing so, when I've inadvisedly CTRL-C'ed rpm (especially before discovering that the version shipped with RH80 was buggy in that it hung at inopportune moments - fixed by installing the version from rpm.org), but that's my problem. Regardless, nothing that removing the database lockfiles and --rebuild'ing the database couldn't fix.
Standard PC power supplies are nothing like 90% efficient largely because of this crude rectification of the mains. Compare the rating of your supply in watts with the input voltage multiplied by the input current. These values should all be marked on the case.
Power Factor Corrected (PFC) supplies are available. The better ones use a switch mode circuit to charge the reservoir capacitor through most of the main power cycle, while the less good ones incorporate a capacitor across the mains to buffer the large peaks of current when the input voltage exceeds that stored in the reservoir capacitor.
Not a rhetorical question, but is PFC really that much of an unusual feature when even cheap PSUs claim to have it?
Other than that, I've never seen any good centralized repository of information like that. Too bad, because it would be useful.
I'm in the market for a decent stereo/HT system right now, and found audiotools.com's directory of manufacturers last night. It makes for useful reading.
I would be cautious with using no-name PC-peripherals, such as printers, scanners, cameras and such. You will soon find out that they will have no drivers available at their website, which will make the product worthless the moment you switch os-es or have lost your installation CD.
That's a very valid point if you're still living in Windows-land, but in Linux-land, I find the no-name generics a better buy, provided that the build quality is high enough. The generics tend to have less in the way of proprietary 'usability features' (which usually aren't!) and gratuitious modifications so the device won't work with a generic driver for the chipset that's been used.
The bottom line is to get the best sound, you have to match your playback equipment with the way the audio was recorded. For watching DVD movies or HDTV, that means 5.1 - that is how these formats are recorded and mixed.
Well, sort of - with the exception of live music DVDs (and even then, not always...), the surround effects are usually dubbed on afterwards, kinda like CGI. The more I think about it, the more I think surround sound is wearing thin for me, in the same way as I'm getting somewhat tired of visual effects-laden movies with no plot.
Now, obviously, a 5.1 system can also be used as a stereo system, so it's not as if you're losing anything for music either.
Well, only if you ignore the various differences in specification between a HiFi amp and a AV amp - distortion, etc. I'm not sure, though, how much these specifications make a difference to the sound as you or I would perceive it (as opposed to measuring it) though, since I don't have a similar-quality/priced HiFI amp and an AV amp to compare side-by-side.
USB and Firewire allow devices to peek/poke through (physical) memory at will.
I'm pretty sure the functionality you describe is only available to Firewire devices, not USB devices, because only Firewire devices can initiate peer-to-peer DMA transfers.
I am, however, waiting for auto-0wning Firewire dongles to turn up on the underground/import market...
1) Windows finally gets a stateful firewall and su
[...]
4) Windows finally gets a decent grep/locate
5) Windows finally gets yum/apt
6) MP3 players and DVD creators? Yeah, we've had those a while, too...
[...]
8) Windows finally gets tar?
9) Windows finally gets Wikis
10) Most binary Linux distros have done a typical desktop install in about the same time. For years already.
Don't worry - it's not like all of the oil in the world will stop at once.
Day N-1: oil is $100/barrel...
Day N: Sorry, no more oil.
It won't happen that way. As we come to an end of oil supply (if ever) the price will obviously rise, but it won't do that overnight either.
I've thought about that, but I'm somewhat concerned that it might be in the oil producers' interests to deliberately distort prices downwards in order to put off the day at which serious migration to non-oil energy sources occurs. They'd obviously like to sell every drop of oil they have, and would rather not be left with billions of barrels left in the ground, being pumped by expensive rigs that haven't yet recouped their investment. This issue occurred to me after Shell was forced to restate its reserves downwards four times during the first half of 2004.
Hopefully, things will work out as you say, and the invisible hand has already begun to do its job, but I fear that if we're complacent that it will, then it won't.
Didn't the "Plus 4" come out at roughly the same time as the Sinclair Spectrum "Plus 2" or whatever it was called, once Amstrad had bought up Sinclair?
No, the Plus 4 came out a couple of years (1984) before Amstrad bought Sinclair and launched the +2 (1987).
Oh, and my first 'real' computer (as opposed to TV game) was a 16KB ZX Spectrum, traded in under warranty for a 48KB model after the keyboard template began to lose its adhesion to the rest of the case.
Since nearly all modern drives remap bad sectors automagically unless they're in truly pitiful shape
Not quite automagically - every time I've had a bad block develop, the drive has only remapped it on writing to it. Reading just returns various types of error (makes sense - if you're trying to recover the block in question, it might read successfully one time in a thousand, then you can write it back, and all is well again). I'm pretty sure that SCSI can return warnings that a block was hard to read, allowing the OS to rewrite the block. Evidence I've seen suggests *BSD makes use of this approach to try and pre-empt failed blocks.
Couldn't you set the swap to run on a Fast Flash Disk? That would allow for faster swapping (or paging for the Winders crowd). I've been meaning to try this, but I don't know how much they cost.
You could do, but if you're not swapping at or, or you're only swapping out idle processes and rarely bringing them back in, it won't make a blind bit of difference.
Also flash memory (which I presume the 'Fast Flash Disk' uses) has a limited number of writes, and attempting to use it as swap will kill it in a very short period of time.
No, that's exactly my point; AMD's HyperTransport allows memory bandwidth to scale in proportion to the number of processors in a system. Intel don't have an equivalent technology, yet, ergo, memory performance gets worse and worse as you add more processors to an Intel-based SMP machine (using standard Intel chipsets, anyway - I wouldn't be at all surprised if some high-end "supercomputer" manufacturer has a custom chipset for Intel CPUs that gives equivalent-or-better performance, but you won't find it on your favourite Asus, Giga-Byte or MSI motherboard).
Re:Scoffing Posts Are From Those With Sort/No Memo
on
Hard Drive Memory Lane
·
· Score: 1
The first HDD I bought was as GVP Series II SCSI sidecar for my Amiga 500. It included a 120MB Maxtor drive, and cost £489 in early 1993. The last HDD I acquired was a 40GB drive that someone gave me after upgrading his TiVo. I currently have about 805GB worth of HDDs, most in active use.
Re:depends on how you measure improvements
on
Hard Drive Memory Lane
·
· Score: 2, Interesting
For the majority of use the speed of even slow drives is plenty fast. The main problem is that most computers have way to little RAM which means the system has to swap which slows the system in general.
Actually, I'd dispute that. Even el-cheapo Dell models now come with 512MB of RAM. I have 512MB on my FC3 workstation and that still leaves me with ~200MB for buffers/cache in normal usage (Windows XP is a different matter, however).
I'd argue that these days, architecturally speaking, the front-side bus is probably the greatest bottleneck, relative to the speed of CPUs. You can work around it by making caches larger and larger, but those caches need to be filled from somewhere, and meanwhile, it makes caching the wrong thing through mis-prediction even more expensive. This is even more pertinent to SMP systems that don't have dedicated memwory buses for each CPU.
Learning assembler to me would be like learning olde English (I played around with it once)
For most things now, even C++ is too low.
Maybe so - certainly you should always pick the most appropriate tool for the job (and I'm a fine one to speak as I usually assault the problems I have to solve with my pair of bash-shaped and C-shaped hammers until they become base- or C-shaped nails!). But whenever you're writing code, you should have at least a vague idea about what kind of machine instructions your program is going to be transformed into. Otherwise a) "People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird." - Knuth b) it comes in handy when you suspect a compiler/interpreter bug c) sometimes, albeit increasingly rarely, assember is the most appropriate tool for the job. Consequently not learning assembler/C/C++ places artificial constraints on that.
My experiences were somewhat similar; I had a Sinclair Spectrum at home, and a friend taught me how to solder (his dad repaired photocopiers and the like) and a couple of adult members of the local computer club got me started with assembly language, but the rest I had to learn from books and magazines, and often without access to equipment, tools or parts to be able to test things myself. Also, I'd quite often get so far, then hit a brick wall, and could find no-one to show me the next stage. If I'd had Google back then, I probably could have learnt a lot more.
I recommend doing all your installation behind a cheap cable/DSL router; this will block any incoming traffic from reaching the machine. Unless you decide to go surfing around on suspect web sites with the incompletely updated machine, you're pretty much guaranteed not to get 0wn3d.
I do so already, on my own network. But work is a university network which has been around for ~20 years with thousands of semi-autonomously administered hosts, so we have to assume it's nearly as hostile as the greater Internet. For now, anyway. But I'm working on fixing that.:-]
Combine some selective slipstreaming with the unattended build facility, e.g. using http://unattended.sourceforge.net/>unattended. My colleagues slipstream service packs and critcial hotfixes (i.e. those that can result in ones machine being 0wn3d during the install) into the installation image, then have a manually-updated.CMD script that runs on the first boot to bring in the others.
Prism based cards should JFW with the prism54 driver. Be careful though, as many cards which once were Prism 2.5-based, aren't any longer - which is why Solwise list the chipsets in each of the WLAN cards they sell.
Slashdot Mirror
I can't speak for SuSE, but all the GUI tools in RH-alike distros do is modify files under /etc, and especially /etc/sysconfig. Read those files, and the initscripts in /etc/init.d that parse them, and you'll be well-equipped to go hacking them yourself. Sometimes this is even necessary in order to achieve some specialised or otherwise unsupported goal.
Not at all. But SuSE has Slackware in its distant ancestry, despite using RPM packages.
You forgot option 3 - wait for your chosen distro vendor to integrate it into one of their future releases. If this doesn't happen quickly enough for you, consider switching distro. The best way to think of the FOSS world is like a perpetual 'technology preview programme'. This is no different to life in Windows-world or Solaris-world. If I see a neat feature in a beta of Windows Vista, but want it NOW in Windows XP, I either get to work to make it happen (subject to coding prowess, source code availability and licensing restrictions) or wait for Vista to show up on the shelves. I don't see why anyone holds FOSS OSs to a higher standard than any other OS.
If you think waiting for a future distro release isn't the right answer for the majority of non- or less-technical users, and that obtaining good packages is slow and/or difficult, perhaps you should start a business offering a packaging service?
Dell repersents his customers... the ones he already has. If the Linux community want to sell Linux to Dell and his customers, then they have give Dell (and by extension, his customers) what he wants.
Thing is, the mythical 'Linux community' doesn't exist in the form you seem to think it does. The 'Linux community' just wants to build, use and share useful software. Another, separate group - Dell customers - apparently increasingly want to buy computers with some flavour of GNU/Linux preloaded, and Dell would like a slice of that market. It's therefore up to Dell to find a distro, selection of distros, or roll their own distro that suits the hardware they're shipping, the majority of their target market, and at a cost Dell is prepared to pay. If they don't want to do that (and perhaps it's just not a profitable market for Dell to be in), they'll have to put up with being shut out of that market, and the customers will have to put up with not being able to get a Dell-priced PC with Linux preloaded. Sooner or later, though, one side will buckle, or a competitor to Dell will arrive on the market who is prepared to do the legwork in order to sell such machines.
Your hardware must be flaky. I've been using RH since 2.1 and have never had RPM trash (i.e. lose entirely, lose substantial portions thereof, or be otherwise corrupted so badly as to force a reinstall) my database. I've come close to doing so, when I've inadvisedly CTRL-C'ed rpm (especially before discovering that the version shipped with RH80 was buggy in that it hung at inopportune moments - fixed by installing the version from rpm.org), but that's my problem. Regardless, nothing that removing the database lockfiles and --rebuild'ing the database couldn't fix.
Most cheap ones use the less good method he referred to(Often called 'passive' vs. 'active' PFC, in PSU literature.)
Excellent! Thanks for the informative post. And indeed, now I know the keywords, google finds lots of useful pages including this one from Seasonic.
Power Factor Corrected (PFC) supplies are available. The better ones use a switch mode circuit to charge the reservoir capacitor through most of the main power cycle, while the less good ones incorporate a capacitor across the mains to buffer the large peaks of current when the input voltage exceeds that stored in the reservoir capacitor.
Not a rhetorical question, but is PFC really that much of an unusual feature when even cheap PSUs claim to have it?
I'm in the market for a decent stereo/HT system right now, and found audiotools.com's directory of manufacturers last night. It makes for useful reading.
That's a very valid point if you're still living in Windows-land, but in Linux-land, I find the no-name generics a better buy, provided that the build quality is high enough. The generics tend to have less in the way of proprietary 'usability features' (which usually aren't!) and gratuitious modifications so the device won't work with a generic driver for the chipset that's been used.
Well, sort of - with the exception of live music DVDs (and even then, not always...), the surround effects are usually dubbed on afterwards, kinda like CGI. The more I think about it, the more I think surround sound is wearing thin for me, in the same way as I'm getting somewhat tired of visual effects-laden movies with no plot.
Now, obviously, a 5.1 system can also be used as a stereo system, so it's not as if you're losing anything for music either.
Well, only if you ignore the various differences in specification between a HiFi amp and a AV amp - distortion, etc. I'm not sure, though, how much these specifications make a difference to the sound as you or I would perceive it (as opposed to measuring it) though, since I don't have a similar-quality/priced HiFI amp and an AV amp to compare side-by-side.
I'm pretty sure the functionality you describe is only available to Firewire devices, not USB devices, because only Firewire devices can initiate peer-to-peer DMA transfers.
I am, however, waiting for auto-0wning Firewire dongles to turn up on the underground/import market...
1) Windows finally gets a stateful firewall and su
[...]
4) Windows finally gets a decent grep/locate
5) Windows finally gets yum/apt
6) MP3 players and DVD creators? Yeah, we've had those a while, too...
[...]
8) Windows finally gets tar?
9) Windows finally gets Wikis
10) Most binary Linux distros have done a typical desktop install in about the same time. For years already.
I really can't see anything compelling there...
Day N-1: oil is $100/barrel...
Day N: Sorry, no more oil.
It won't happen that way. As we come to an end of oil supply (if ever) the price will obviously rise, but it won't do that overnight either.
I've thought about that, but I'm somewhat concerned that it might be in the oil producers' interests to deliberately distort prices downwards in order to put off the day at which serious migration to non-oil energy sources occurs. They'd obviously like to sell every drop of oil they have, and would rather not be left with billions of barrels left in the ground, being pumped by expensive rigs that haven't yet recouped their investment. This issue occurred to me after Shell was forced to restate its reserves downwards four times during the first half of 2004.
Hopefully, things will work out as you say, and the invisible hand has already begun to do its job, but I fear that if we're complacent that it will, then it won't.
No, the Plus 4 came out a couple of years (1984) before Amstrad bought Sinclair and launched the +2 (1987).
Oh, and my first 'real' computer (as opposed to TV game) was a 16KB ZX Spectrum, traded in under warranty for a 48KB model after the keyboard template began to lose its adhesion to the rest of the case.
Not quite automagically - every time I've had a bad block develop, the drive has only remapped it on writing to it. Reading just returns various types of error (makes sense - if you're trying to recover the block in question, it might read successfully one time in a thousand, then you can write it back, and all is well again). I'm pretty sure that SCSI can return warnings that a block was hard to read, allowing the OS to rewrite the block. Evidence I've seen suggests *BSD makes use of this approach to try and pre-empt failed blocks.
Turn your speakers/headphones down before you start.
You could do, but if you're not swapping at or, or you're only swapping out idle processes and rarely bringing them back in, it won't make a blind bit of difference.
Also flash memory (which I presume the 'Fast Flash Disk' uses) has a limited number of writes, and attempting to use it as swap will kill it in a very short period of time.
No, that's exactly my point; AMD's HyperTransport allows memory bandwidth to scale in proportion to the number of processors in a system. Intel don't have an equivalent technology, yet, ergo, memory performance gets worse and worse as you add more processors to an Intel-based SMP machine (using standard Intel chipsets, anyway - I wouldn't be at all surprised if some high-end "supercomputer" manufacturer has a custom chipset for Intel CPUs that gives equivalent-or-better performance, but you won't find it on your favourite Asus, Giga-Byte or MSI motherboard).
The first HDD I bought was as GVP Series II SCSI sidecar for my Amiga 500. It included a 120MB Maxtor drive, and cost £489 in early 1993. The last HDD I acquired was a 40GB drive that someone gave me after upgrading his TiVo. I currently have about 805GB worth of HDDs, most in active use.
Actually, I'd dispute that. Even el-cheapo Dell models now come with 512MB of RAM. I have 512MB on my FC3 workstation and that still leaves me with ~200MB for buffers/cache in normal usage (Windows XP is a different matter, however).
I'd argue that these days, architecturally speaking, the front-side bus is probably the greatest bottleneck, relative to the speed of CPUs. You can work around it by making caches larger and larger, but those caches need to be filled from somewhere, and meanwhile, it makes caching the wrong thing through mis-prediction even more expensive. This is even more pertinent to SMP systems that don't have dedicated memwory buses for each CPU.
For most things now, even C++ is too low.
Maybe so - certainly you should always pick the most appropriate tool for the job (and I'm a fine one to speak as I usually assault the problems I have to solve with my pair of bash-shaped and C-shaped hammers until they become base- or C-shaped nails!). But whenever you're writing code, you should have at least a vague idea about what kind of machine instructions your program is going to be transformed into. Otherwise a) "People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird." - Knuth b) it comes in handy when you suspect a compiler/interpreter bug c) sometimes, albeit increasingly rarely, assember is the most appropriate tool for the job. Consequently not learning assembler/C/C++ places artificial constraints on that.
My experiences were somewhat similar; I had a Sinclair Spectrum at home, and a friend taught me how to solder (his dad repaired photocopiers and the like) and a couple of adult members of the local computer club got me started with assembly language, but the rest I had to learn from books and magazines, and often without access to equipment, tools or parts to be able to test things myself. Also, I'd quite often get so far, then hit a brick wall, and could find no-one to show me the next stage. If I'd had Google back then, I probably could have learnt a lot more.
I do so already, on my own network. But work is a university network which has been around for ~20 years with thousands of semi-autonomously administered hosts, so we have to assume it's nearly as hostile as the greater Internet. For now, anyway. But I'm working on fixing that. :-]
Combine some selective slipstreaming with the unattended build facility, e.g. using http://unattended.sourceforge.net/>unattended. My colleagues slipstream service packs and critcial hotfixes (i.e. those that can result in ones machine being 0wn3d during the install) into the installation image, then have a manually-updated .CMD script that runs on the first boot to bring in the others.
Prism based cards should JFW with the prism54 driver. Be careful though, as many cards which once were Prism 2.5-based, aren't any longer - which is why Solwise list the chipsets in each of the WLAN cards they sell.