Press and prepress users need it, as do print designers and layout staff. Ad agencies may also need it, if they submit ads in PDF form to be embedded into the final layout as-is (and generally they do).
A designer needs to be able to see out of gamut colour (colour that can not print on their output device / colour space), so they can adjust their image not to change too much when printed in CMYK. You see, the CMYK and RGB colour spaces do not both contain the same set of colours, so some RGB colours cannot be reproduced in CMK and vice versa. Additionally, some output devices have even more restricted colour spaces, such as a litho press for newsprint.
Having someone's blue shirt come out purple in print is an unpleasant experience that's to be avoided. CMYK support and colour management both help avoid this. If the blue-now-purple shirt is a full page advertisment, you'll care about this when the advertiser comes a-knocking.
In general, most colour adjustment for print should be done in RGB (it's easier to control colour in RGB) but previewed in CMYK so you can get a better idea of how it'll print. In the GIMP as things stand, you can't really see how your work will print.
Calibrating your display is only half the story. If you don't have proper ICC profiles for your output device (printer / press), then it does you relatively little good. If you do have a properly calibrated display and suitable output device profiles, plus tools capable of previewing your work according to the output profile, then you may stand a chance of getting decent quality, accurate colour in print.
CMYK support is a pre-requisite for press colour management support. CMYK by its self is helpful, especially with an out-of-gamut warning, but only really comes into its own when combined with colour management.
I think you'll find, frankly, that the majority of people who know what CMYK _is_ will have a legitimate need for support for it. Most people neither know nor care.
It'd be nice if Postfix was as simple as SpamAssassin. Unfortunately, MTAs are complex - mostly because the Internet and eMail are complex, and because of all the ugly hacks and workarounds required to actually get mail to and from lots of the the utterly broken garbage that claim they're mailservers.
Postfix can, however, be a fantastic front line of defence for people who get so much spam that SpamAssassin alone can't cope, or who want to reduce the considerable system loads imposed by running SpamAssassin on a large volume of mail.
If SpamAssassin does the job well enough that learning advanced Postfix configuration isn't worth your time, that's fine. It _is_ worth it for some, though, and those people don't much care that it takes a wee while - they want to make sure they don't lose mail, and they want to save time in the long term by cutting down spam. Those goals are worth a bit of short-term time cost.
Few mail installations are the same, as few sites have the same requirements and make different choices on trade-offs like false positives vs block rates, and compatibility with broken mail servers. This means that Postfix needs to be configurable.
Given just how configurable it is, I think it does a good job of being fairly easy to configure.
Minor problem: A percentage stays the same if you multiply the base quantity it refers to.
5% is still 5%, whether over 100 messages or 100,000.
I can personally attest to good results with a wee bit of work on my Postfix config. I was unwilling to be as draconian in my policy as this poster must've been, so I was only able to block about 60%.
I'm in a similar situation - a search for 'craig@postnewspapers.com.au' on Google returns a fairly hefty number of hits. Slightly more than your address, in fact:-P
I get massively less spam than you - around 300 a day, though most of it gets stopped dead at the mail gateway by ordb.org and dsbl.org checks. I get about 100 or so spam actually delivered, and SA (set to be pretty forgiving) filters out all but 10 or so per day. I don't envy being in your position.
Viruses, however, are another story. I haven't seen one in six months - it's fantastic. A combination of some postfix rules and ClamAV on the internal (sendmail) mail server did the trick. If you run postfix at your mail gateway, you can get it to check incoming mail for suspicious filenames before it even accepts the mail:
mine_header_checks_pcre: ---- # Try to kill common Windows executables early, and give a useful message /^Content-(Disposition|Type):.*name="?([^ >;]*)\.(exe|bat|com|pif|vb|lnk|scr|reg|chm|wsh|js| inf|shs|job|ini|shb|scp|scf|wsc|sct|dll)"?/ REJECT Microsoft Windows Executables (like suspect file "$2.$3") not accepted here. If you were sending a self extracting zip file, please send a non-self-extracting version instead.
(note: the regexp and message are all on one line, though I should move to an extended regex and split it up).
*blam*. There goes 99% of your incoming virus mail. ClamAV gets the rest, so I just don't get viruses anymore. Best of all, you're not generating bounces for virues, you're rejecting them instantly - so unless they're using some dumb bastard to relay, there won't be any mess of bounces to falsified addreses to worry about.
What about the new waves of self-zipping viruses, you ask? Yeah, that's an issue. I cheat and quarantine all zip files. I rarely have to retrieve one, and it's well worth the saved fuss.
As for mail programs, I'm happily using Evolution with IMAP over a 512k/256k effective link to work's Cyrus IMAPd server (all this stuff is set up for work). It works great, and I'm able to use 20,000 message mailboxes without noticable stress. Sieve (the cyrus IMAPd filter language) filters everything into the right mailboxes server-side, so if I'm in a hurry I just read my (always small and managable) INBOX without worrying about my lists.* folders, the (server-side filtered) Junk folder, or anything else.
I think you'd hate Photoshop on MacOS just as much. It also uses lots of floating palettes, etc.
I, on the other hand, flip out completely trying to use what I find to be a horrible MDI interface for Phoshop on Windows. I find both the GIMP and Photoshop/Mac <i>much</i> more usable than Photoshop/Windows.
On X11, GIMP's "native" environment, it's possible to control all this stuff at the window manager level (assuming your window manager is not too dumbed down to let you - grr). You can lock windows into layers, force them to be on top, make them sticky so they show on all virtual desktops, etc. It's a level of control that lets you match the MDI of Photshop/Windows if you want, or make the app work how _you_ like it.
I think a key issue is that Windows doesn't give you this control, so GIMP on Windows is quite a bit harder to use:-(
This dicussion has been done to death in many previous Slashdot posts, but I'm going to bite anyway.
The Photoshop interface is far from perfect, too. I have new users at work who have been exposed to both the GIMP and Photoshop 7/MacOS, and they find things confusing and difficult in both. Users tend to be able to unable to find functionalty, and tend to be unable to retrieve palettes etc when they close them. It seems to be roughtly the same for both apps.
Of course, our experienced Photoshop users are lost in the GIMP. This is unsurprising - it's new and different, after all - and if you're an experienced Photoshop user then I don't doubt you'll find the interface difficult. I use both programs quite comfortably, myself, but I seem to be in the minority.
I _hated_ the GIMP 1.x interface, but I personally think they've done so much to improve usability in 2.0 that it's on par with Photoshop - just different.
Most importantly, I'd strongly prefer different but good to the hideous mostly-similar ugly kind-of-works interface cloning approach of OpenOffice.
I wouldn't mind a Photoshop interface _option_ for the GIMP, but I think the core GIMP developers probably have much better things to do with their time. It's a good thing for the (apparently many) people who want one to think about getting together and writing. Yes, I _do_ speak from experience, having pulled out my thumb and started working on issues that really irritate me in Scribus.
As for colour management,/there/ I entirely agree with you. If you're not just doing web development, colour management matters. Perhaps even more critical for many uses is proper CMYK support (this generally ties in rather tightly to colour management support). There is primitive support now via a plug-in, but I'm not aware of any good, solid colour management / CMYK support for the GIMP yet:-(.
As for the widgets... that's just not a GIMP problem. Gtk widgets can be changed using gtk themes and engines. Anyway, as you seem to feel the strong desire to replace the entire UI, that'd be an ideal opportunity to replace the widget set too;-)
I'm amused to note that, were this post about MSIE's stability decreasing between a beta and final release, few on Slashdot would be saying "Go discuss this in a newsgroup."
Fair enough. It's far from unlikely that my interpretation was too forgiving, but I think Groklaw's is definitely pushing it well beyond reasonable.
Of course, I've been finding myself of that view more and more about Groklaw. I'm bothered by the "I'm a journalist" line and the total lack of basic journalistic practices like trying to distinguish personal opinion and interpretation from reported events sort of bothers me.
Uggh. I really wish the whole affair would just _go_ _away_.
That's incorrect. The quoted text states that they won't indemnify you if suit is bought against you or there is a negative ruling against you because of non-microsoft software on your systems.
More likely they'll go after the big fish first, then you smaller players later.
I just don't think that's true at all.
The litigation companies go after a series of smaller operators first, forcing them to settle or driving them to a loss in court. They use this series of "victories" to help bolster the legitimacy of their patent when going after bigger companies with deeper pockets who can afford decent lawyers.
It's not necessarily the money you make, however. It's the money you cost the other company. That may be a very different matter indeed.
If you make software and sell it for $500 that does the same job as ${BIGCOMPANY}'s $100,000 software, it may not take long for them to come after you.
Regarding the Apache and BSD licenses, I tend to agree.
When it comes to the GPL, I agree that is a restrictive license, and "less free" than the BSD/X11/MIT/Apache licenses. I can't say I agree with the rest, though.
GPLed works generally belong to no one person or organisation, true. This doesn't always have to be the case (take Asterisk or all FSF software, for example) but generally is. The difference is that I don't see how that's a problem, if all authors/contributors have decided that that license is appropriate for their work. In fact, surely it's much the same as a distributed group of people working on closed source software - the codebase doesn't belong to any one of them - except that the GPL developers let you use their work under a different set of conditions?
You do not lose the rights to your work if you incorporate GPL code. You will generally have the option, much the same as for any other copyright infringement, of removing and rewriting that portion of the code. You may have to pay damages or settle for other remedies, especially if the copying was knowing. The difference between the GPL and a proprietary license is that it offers you the/option/ of releasing your work under the same license as another way to escape the infringement. Sometimes that might be appropriate, but when it isn't it just comes down to another copyright infringement / license violation case.
The point is that in many ways the GPL is just another proprietary license, it just gives you different options and a different set of restrictions. Many find it much easier to agree with than other licenses, many others find it impossible to accept. So what? Your own view undermines your complaints - if the authors of GPL works had wanted their work free for everybody to use however they wanted, the would've released under the BSD license or similar. Complaining that they didn't has as much validity as if I complain that your work isn't released under the BSD license, because I want to use it in my work without offering you any compensation.
Regarding libraries, the library author should release under the LGPL if they want a GPL-style license but to still have their work usable with closed-source software.
Some don't want closed-source developers to be able to use their work. That's OK - but I don't think their work should be made a core part of operating systems.
I, personally, would probably choose either the LGPL or BSD license for any significant library I wrote, depending on the library and it's intended use. Smaller/simpler stuff I'd just release under the BSD license simply to make it easier to use.
Your viewpoint seems to omit the idea that open source / free software developers may not wish closed source developers to be able to use their code. I don't doubt that's frustrating, but they really have as much right to make that decision with their work as you do to sell yours as closed source. Hell, it frustrates me - I'm working on an in-house app and we want to maintain the freedom to choose our license if/when we release the app more widely.
The key point is that GPL and LGPL authors are not releasing their work to the commons / public domain. They're releasing it under a restrictive license, just one that's restrictive in very unconventional ways. You're not _supposed_ to be able to use it, any more than you can borrow code from Microsoft's shared source programme or bundle their OS or app DLLs because there's something convenenient in them.
No. You are not allowed to redistribute modified copies without providing the source to your modified copy.
In that sense, it's more restrictive than the BSD/X11 license.
It's great for users and consultants, but does put pressure on professional coders, especially small scale ones. In the end, though, the industry does shift over time - perhaps it's time to retrain to focus on making custom enhancements to tools.
Your modem is already forbidden to send high voltages down the wire. It must be FCC certified to be permitted to connect to the phone network.
Hopefully, they just mean to apply the same requirements to WANs. Frankly, I doubt it - it looks like a power grab.
Knowing the FCC - and Bush - it seems likely to me that they're probably going to start proposing impractical and heavy handed "solutions" to problems like botnets. This is probably also another attempt to gain control over VoIP - they seem to want that _very_ badly.
Yeah, that's fair and accurate. I've noticed a lot of people cycling that way. Frankly, I've been guilty of it myself, though generally only in near-zero traffic (eg middle of the night).
Unfortunately, there is no such thing as the giant cyclist overmind to make the decision. It's individual, much like driving like a moron or driving sensibly is. Consequently, you'll see cyclists riding like maniacs, sensible cyclists, agressive rules lawyers, and some who combine two or three of of those traits. Not much to be done about it really.
I'm not too sure about that myself. A definitely-non-geek friend of mine can use SQL and VB (yeah, I know...) when pressed to do so.
I think the main thing is that few but geeks every have the inclination to learn programming in the first place. Most (non-stupid) people who have not already decided it's "too hard" or "scary" can manage programming... they just normally don't care to.
The PPro may have been over-hyped, but it _was_ a seriously good chip. In fact, it heralded the best line of CPUs Intel ever produced, the PII/PIII/PM line. They're currently in the process of ditching the Pentium 4 to go _back_ to the PM, which is at heart a PPro. The PPro also spawned the Xeon line, until Intel moved it across to Pentium 4 a while ago. The PIII Xeon was a _mightly_ fine chip.
Overall... I'd argue that the PPro really did deliver.
Slashdot Mirror
Press and prepress users need it, as do print designers and layout staff. Ad agencies may also need it, if they submit ads in PDF form to be embedded into the final layout as-is (and generally they do).
A designer needs to be able to see out of gamut colour (colour that can not print on their output device / colour space), so they can adjust their image not to change too much when printed in CMYK. You see, the CMYK and RGB colour spaces do not both contain the same set of colours, so some RGB colours cannot be reproduced in CMK and vice versa. Additionally, some output devices have even more restricted colour spaces, such as a litho press for newsprint.
Having someone's blue shirt come out purple in print is an unpleasant experience that's to be avoided. CMYK support and colour management both help avoid this. If the blue-now-purple shirt is a full page advertisment, you'll care about this when the advertiser comes a-knocking.
In general, most colour adjustment for print should be done in RGB (it's easier to control colour in RGB) but previewed in CMYK so you can get a better idea of how it'll print. In the GIMP as things stand, you can't really see how your work will print.
Calibrating your display is only half the story. If you don't have proper ICC profiles for your output device (printer / press), then it does you relatively little good. If you do have a properly calibrated display and suitable output device profiles, plus tools capable of previewing your work according to the output profile, then you may stand a chance of getting decent quality, accurate colour in print.
CMYK support is a pre-requisite for press colour management support. CMYK by its self is helpful, especially with an out-of-gamut warning, but only really comes into its own when combined with colour management.
I think you'll find, frankly, that the majority of people who know what CMYK _is_ will have a legitimate need for support for it. Most people neither know nor care.
It'd be nice if Postfix was as simple as SpamAssassin. Unfortunately, MTAs are complex - mostly because the Internet and eMail are complex, and because of all the ugly hacks and workarounds required to actually get mail to and from lots of the the utterly broken garbage that claim they're mailservers.
Postfix can, however, be a fantastic front line of defence for people who get so much spam that SpamAssassin alone can't cope, or who want to reduce the considerable system loads imposed by running SpamAssassin on a large volume of mail.
If SpamAssassin does the job well enough that learning advanced Postfix configuration isn't worth your time, that's fine. It _is_ worth it for some, though, and those people don't much care that it takes a wee while - they want to make sure they don't lose mail, and they want to save time in the long term by cutting down spam. Those goals are worth a bit of short-term time cost.
Few mail installations are the same, as few sites have the same requirements and make different choices on trade-offs like false positives vs block rates, and compatibility with broken mail servers. This means that Postfix needs to be configurable.
Given just how configurable it is, I think it does a good job of being fairly easy to configure.
Minor problem: A percentage stays the same if you multiply the base quantity it refers to.
5% is still 5%, whether over 100 messages or 100,000.
I can personally attest to good results with a wee bit of work on my Postfix config. I was unwilling to be as draconian in my policy as this poster must've been, so I was only able to block about 60%.
I get massively less spam than you - around 300 a day, though most of it gets stopped dead at the mail gateway by ordb.org and dsbl.org checks. I get about 100 or so spam actually delivered, and SA (set to be pretty forgiving) filters out all but 10 or so per day. I don't envy being in your position.
Viruses, however, are another story. I haven't seen one in six months - it's fantastic. A combination of some postfix rules and ClamAV on the internal (sendmail) mail server did the trick. If you run postfix at your mail gateway, you can get it to check incoming mail for suspicious filenames before it even accepts the mail:(note: the regexp and message are all on one line, though I should move to an extended regex and split it up).
*blam*. There goes 99% of your incoming virus mail. ClamAV gets the rest, so I just don't get viruses anymore. Best of all, you're not generating bounces for virues, you're rejecting them instantly - so unless they're using some dumb bastard to relay, there won't be any mess of bounces to falsified addreses to worry about.
What about the new waves of self-zipping viruses, you ask? Yeah, that's an issue. I cheat and quarantine all zip files. I rarely have to retrieve one, and it's well worth the saved fuss.
As for mail programs, I'm happily using Evolution with IMAP over a 512k/256k effective link to work's Cyrus IMAPd server (all this stuff is set up for work). It works great, and I'm able to use 20,000 message mailboxes without noticable stress. Sieve (the cyrus IMAPd filter language) filters everything into the right mailboxes server-side, so if I'm in a hurry I just read my (always small and managable) INBOX without worrying about my lists.* folders, the (server-side filtered) Junk folder, or anything else.
It's great.
I think you'd hate Photoshop on MacOS just as much. It also uses lots of floating palettes, etc.
:-(
I, on the other hand, flip out completely trying to use what I find to be a horrible MDI interface for Phoshop on Windows. I find both the GIMP and Photoshop/Mac <i>much</i> more usable than Photoshop/Windows.
On X11, GIMP's "native" environment, it's possible to control all this stuff at the window manager level (assuming your window manager is not too dumbed down to let you - grr). You can lock windows into layers, force them to be on top, make them sticky so they show on all virtual desktops, etc. It's a level of control that lets you match the MDI of Photshop/Windows if you want, or make the app work how _you_ like it.
I think a key issue is that Windows doesn't give you this control, so GIMP on Windows is quite a bit harder to use
This dicussion has been done to death in many previous Slashdot posts, but I'm going to bite anyway.
/there/ I entirely agree with you. If you're not just doing web development, colour management matters. Perhaps even more critical for many uses is proper CMYK support (this generally ties in rather tightly to colour management support). There is primitive support now via a plug-in, but I'm not aware of any good, solid colour management / CMYK support for the GIMP yet :-( .
... that's just not a GIMP problem. Gtk widgets can be changed using gtk themes and engines. Anyway, as you seem to feel the strong desire to replace the entire UI, that'd be an ideal opportunity to replace the widget set too ;-)
The Photoshop interface is far from perfect, too. I have new users at work who have been exposed to both the GIMP and Photoshop 7/MacOS, and they find things confusing and difficult in both. Users tend to be able to unable to find functionalty, and tend to be unable to retrieve palettes etc when they close them. It seems to be roughtly the same for both apps.
Of course, our experienced Photoshop users are lost in the GIMP. This is unsurprising - it's new and different, after all - and if you're an experienced Photoshop user then I don't doubt you'll find the interface difficult. I use both programs quite comfortably, myself, but I seem to be in the minority.
I _hated_ the GIMP 1.x interface, but I personally think they've done so much to improve usability in 2.0 that it's on par with Photoshop - just different.
Most importantly, I'd strongly prefer different but good to the hideous mostly-similar ugly kind-of-works interface cloning approach of OpenOffice.
I wouldn't mind a Photoshop interface _option_ for the GIMP, but I think the core GIMP developers probably have much better things to do with their time. It's a good thing for the (apparently many) people who want one to think about getting together and writing. Yes, I _do_ speak from experience, having pulled out my thumb and started working on issues that really irritate me in Scribus.
As for colour management,
As for the widgets
I'm amused to note that, were this post about MSIE's stability decreasing between a beta and final release, few on Slashdot would be saying "Go discuss this in a newsgroup."
Good point. In fact, in the case where you're comparing two pointers, the result of ;-)
&a == &b
will not be quite what you were hoping
This operator _does_ exist in Python, so it'd be more than a tad frustrating if this patent was granted.
It's very common to do object identity comparisons in Python, such as
if x is not None:
do_something_with(x)
Umm... no, it doesn't.
The Python 'is not' operator does, but to get the same effect in C/C++ you must, as another poster noted, do the equivalent of
&a != &b
to determine if they're the same object. It's not an equality test, it's an identity test.
Fair enough. It's far from unlikely that my interpretation was too forgiving, but I think Groklaw's is definitely pushing it well beyond reasonable.
Of course, I've been finding myself of that view more and more about Groklaw. I'm bothered by the "I'm a journalist" line and the total lack of basic journalistic practices like trying to distinguish personal opinion and interpretation from reported events sort of bothers me.
Uggh. I really wish the whole affair would just _go_ _away_.
That's incorrect. The quoted text states that they won't indemnify you if suit is bought against you or there is a negative ruling against you because of non-microsoft software on your systems.
That's entirely fair.
Arrggh!
Thank you James (or, failing that, thankyou AC).
More likely they'll go after the big fish first, then you smaller players later.
I just don't think that's true at all.
The litigation companies go after a series of smaller operators first, forcing them to settle or driving them to a loss in court. They use this series of "victories" to help bolster the legitimacy of their patent when going after bigger companies with deeper pockets who can afford decent lawyers.
It's not necessarily the money you make, however. It's the money you cost the other company. That may be a very different matter indeed.
If you make software and sell it for $500 that does the same job as ${BIGCOMPANY}'s $100,000 software, it may not take long for them to come after you.
Regarding the Apache and BSD licenses, I tend to agree.
/option/ of releasing your work under the same license as another way to escape the infringement. Sometimes that might be appropriate, but when it isn't it just comes down to another copyright infringement / license violation case.
When it comes to the GPL, I agree that is a restrictive license, and "less free" than the BSD/X11/MIT/Apache licenses. I can't say I agree with the rest, though.
GPLed works generally belong to no one person or organisation, true. This doesn't always have to be the case (take Asterisk or all FSF software, for example) but generally is. The difference is that I don't see how that's a problem, if all authors/contributors have decided that that license is appropriate for their work. In fact, surely it's much the same as a distributed group of people working on closed source software - the codebase doesn't belong to any one of them - except that the GPL developers let you use their work under a different set of conditions?
You do not lose the rights to your work if you incorporate GPL code. You will generally have the option, much the same as for any other copyright infringement, of removing and rewriting that portion of the code. You may have to pay damages or settle for other remedies, especially if the copying was knowing. The difference between the GPL and a proprietary license is that it offers you the
The point is that in many ways the GPL is just another proprietary license, it just gives you different options and a different set of restrictions. Many find it much easier to agree with than other licenses, many others find it impossible to accept. So what? Your own view undermines your complaints - if the authors of GPL works had wanted their work free for everybody to use however they wanted, the would've released under the BSD license or similar. Complaining that they didn't has as much validity as if I complain that your work isn't released under the BSD license, because I want to use it in my work without offering you any compensation.
Regarding libraries, the library author should release under the LGPL if they want a GPL-style license but to still have their work usable with closed-source software.
Some don't want closed-source developers to be able to use their work. That's OK - but I don't think their work should be made a core part of operating systems.
I, personally, would probably choose either the LGPL or BSD license for any significant library I wrote, depending on the library and it's intended use. Smaller/simpler stuff I'd just release under the BSD license simply to make it easier to use.
Your viewpoint seems to omit the idea that open source / free software developers may not wish closed source developers to be able to use their code. I don't doubt that's frustrating, but they really have as much right to make that decision with their work as you do to sell yours as closed source. Hell, it frustrates me - I'm working on an in-house app and we want to maintain the freedom to choose our license if/when we release the app more widely.
The key point is that GPL and LGPL authors are not releasing their work to the commons / public domain. They're releasing it under a restrictive license, just one that's restrictive in very unconventional ways. You're not _supposed_ to be able to use it, any more than you can borrow code from Microsoft's shared source programme or bundle their OS or app DLLs because there's something convenenient in them.
No. You are not allowed to redistribute modified copies without providing the source to your modified copy.
In that sense, it's more restrictive than the BSD/X11 license.
It's great for users and consultants, but does put pressure on professional coders, especially small scale ones. In the end, though, the industry does shift over time - perhaps it's time to retrain to focus on making custom enhancements to tools.
No doubt that's why all their software prints notices that are only a small step above begging for money :-P
Your modem is already forbidden to send high voltages down the wire. It must be FCC certified to be permitted to connect to the phone network.
Hopefully, they just mean to apply the same requirements to WANs. Frankly, I doubt it - it looks like a power grab.
Knowing the FCC - and Bush - it seems likely to me that they're probably going to start proposing impractical and heavy handed "solutions" to problems like botnets. This is probably also another attempt to gain control over VoIP - they seem to want that _very_ badly.
My bet was on Duke Nukem Forever :-P
Yeah, that's fair and accurate. I've noticed a lot of people cycling that way. Frankly, I've been guilty of it myself, though generally only in near-zero traffic (eg middle of the night).
Unfortunately, there is no such thing as the giant cyclist overmind to make the decision. It's individual, much like driving like a moron or driving sensibly is. Consequently, you'll see cyclists riding like maniacs, sensible cyclists, agressive rules lawyers, and some who combine two or three of of those traits. Not much to be done about it really.
I'm not too sure about that myself. A definitely-non-geek friend of mine can use SQL and VB (yeah, I know...) when pressed to do so.
I think the main thing is that few but geeks every have the inclination to learn programming in the first place. Most (non-stupid) people who have not already decided it's "too hard" or "scary" can manage programming... they just normally don't care to.
Don't try that with a car battery ;-)
*looks over at PPro firewall*
... I'd argue that the PPro really did deliver.
The PPro may have been over-hyped, but it _was_ a seriously good chip. In fact, it heralded the best line of CPUs Intel ever produced, the PII/PIII/PM line. They're currently in the process of ditching the Pentium 4 to go _back_ to the PM, which is at heart a PPro. The PPro also spawned the Xeon line, until Intel moved it across to Pentium 4 a while ago. The PIII Xeon was a _mightly_ fine chip.
Overall