Second, early on Amiga floppies had a reputation for being somewhat less reliable than their PC and Atari brethren, though personally, by 1991 when I got a 500+, I didn't see any real difference.
That's probably because the Amiga floppy controller wrote track-at-once, rather than secton-at-once but without either the controller or the trackdisk.device verifying that the entire track had been written correctly. Hence, if you updated a single sector on a track, the entire track would be re-written, and the "unmodified" tracks may get corrupted in the process.
There was a nice hack called TrackSalve which hacked the trackdisk.device so that it performed an automatic verify of tracks after writing. ISTR equivalent functionality may have been incorporated into trackdisk.device in 2.04/3.0+ Kickstarts, but before I started using TrackSalve, I used to frequently end up with corrupted diskette bitmaps (probably the most-rewritten track on an Amiga floppy).
Another, probably less significant factor is that the Amiga disk hardware wrote tracks with no gaps between sectors in order to get that extra 160KBytes. If a PC disk controller encountered an error in the inter-sector gaps, I doubt it would cause it many problems, but for Amigas, it increases the probability that an error will occur in an occupied cell of the disk.
If the program expects command line arguments, and you provide it none, the tradition is to display a short blurb about the program's usage. Is this considered a successful run, or a failure?
I've always regarded that as a failure - the use didn't supply enough information for the program to do its job (hence a failure), but the program dumps some usage information as a convenience to the user. A quick test shows that GNU 'grep' returns 2 in such a case, so that's consistent.
You could argue that it failed in that it didn't do what the program was intended to do (e.g. encode mp3s), but you could also argue that the expected behaviour of the program, when provided zero parameters, is to display usage info, and it successfully did that.
I think you'd be in the minority with your latter argument.
What if, using whatever the proper syntax of the shell is, the user requests something like "encode all wave files in this directory" and there are zero wave files, and so the program encodes zero mp3s. Was that a success or a failure? It's a success in that nothing in the program broke, but it seems like perhaps something happened that the user isn't aware of, and perhaps the user should be informed.
My instinct is that that would depend on how the program is used. If the user needs to supply a list of files (e.g. *.wav before expansion by the shell), then if that list is null, the program should return an error. If, OTOH, the user needs to supply a path which is searched for files, then the program should exit(EXIT_SUCCESS) as long as that path exists and is readable.
What about if the user passes a "-h" parameter, asking for help, and the program displays the help. Was this a successful run of the program or a failure? It did exactly what the user asked, but it didn't fufill its main purpose, encoding mp3s in this example.
Again, convention indicates that a program displaying help if the user explicitly asks for it is successful operation. Some applications (e.g. GUI wrappers for command line applications) use '-h' and '--help' to find out what options are supported by the application they wrap in order to present appropriate controls in the GUI.
What if the user thinks "-h" means "highquality", but in fact the program interprets it as "display help"? The help blurb may be displayed, a success returned, and the files deleted.
OK, a potentially valid point, at last. But what if I think a GUI's "trashcan" icon actually represents a printer and I drag all my files to it hoping for them to be printed? There's a limit to how much you can do to protect the user from their own stupidity or ignorance.
I'm not advocating GUIs vs CLI or vice versa (I alternate between the two, depending on what I'm trying to get done), but I have a distate for Unix's return code system.
It's true that it's a shame that POSIX doesn't appear to define the commonly-accepted conventions I've described above, but this GNU libc manual page is a good start.
I'm interested to hear what would you propose instead of exit codes!
Poor example. First, the time it takes to start the process means extremely little compared to the time lame will take to do its work.
Yes, but a computer should save me, the user time and effort. In many examples (including this one), once the user has got the basic command line vocabulary and syntax, the command line will be more efficient for the user if they're performing a task at all regularly.
IMHO, about the only times a GUI wins are when you're performing some infrequent operation (such that you need to teach or remind yourself of syntax and options each time) and when you need to perform an operation on a bunch of files for which you can't easily come up with a regular expression. Even then, as your experience of regular expressions grows, it becomes easier to compose more elaborate regular expressions such that the CLI starts to win again in the latter scenario.
Second, if you're performing a command like this, especially one involving 'rm', you want to make damn sure there is no mistake. With GUI it's easier to have such a certainty.
It sounds as though you don't understand the '&&' operator - by using that, the OP has ensured that each file will only be removed if lame indicates (using its return code) that it completed successfully. Lame may lie, of course, but if you're concerned about that, then you won't want to automate this job at all. My experience indicates that it's extremely rare for a UNIX tool to lie in its return code value.
This is something that concerns me; because Windows and Windows applications tend to be much less obviously deterministic than other OSs and applications, non-technical users get used to the idea that computers are mysterious, unpredictable devices. Similarly, because Windows error messages are so frequently inaccurate, politically-loaded, or even outright lies, non-technical users get used to ignoring them because they've never found them to be any use in fixing their problems in the past.
Orange's "Where's my nearest?" function which uses the location of your current cell to find the nearest branch of XYZ Ltd, or the nearest XYZ restaurant/garage/whatever.
Googling for Linux compatibility when I see some neat toy at an attractive price.
Attempting to do some basic price checking. This is currently a weak spot, and I think there's a gap in the WAP arena for this.
Reading news headlines/stock prices when I'm in transit and without anything to read.
The restaurant industry is valuable simply because the demand for food, unlike some other products, is never going to go away.
The demand for food may not be going away, but if consumers' disposable income is reduced (say, by increasing interest payments on their debt mountains), then luxuries like going to a nice restaurant will be the first to go. I know this, because this is what I did when I needed to economise whilst running my own business.
I enjoy cooking, so I have considered going into catering, but the above, plus all the niggly things about it (e.g. staying behind 'til 2am to clean up ready for the next day), and a lack of catering trade experience thoroughly put me off. Also, in the same way as I wouldn't feel fulfilled selling bodged computer solutions, I wouldn't feel fulfilled selling cheap n' nasty junkfood (which McDonalds et al can probably do better and cheaper anyway).
One-to-one medical care is pretty damn hard to offshore-outsource, unlike "knowledge industry" jobs like computing, accountancy,... And, for all the hype, medicine probably pays better.
State capitalism? That is an oxymoron. Statism is the opposite of capitalism. There is no such thing as state capitalism. By definition it wouldn't be capitalism. Maybe corporative socialism?.
Howzabout China? Or possibly even the western-style government-industry complexes that Eisenhower warned of if you're being as cynical as me.
...And that's even assuming that productivity is directly proportional to hours worked. For short stretches, it can be. For long stretches, or manual labour, it look as though it won't.
I use an ex-corporate 21" Sun-branded GDM-5010PT which I bought for about 100GBP nearly two years ago. Bargain.
I gave my dad my old 17" monitor, which was a Viglen Envy (probably MAG or something) that my employer had dropped down the stairs whilst moving. It's still working.
The only old monitors I don't still use are my PAL Philips 8852 from my Amiga days, and the 15" Iiyama which I bought with my first PC, back in 1995 for about 300GBP. That's the most expensive monitor I've ever bought!
Ha! I have a ~21" Finlandia (who?) CRT TV that I've had just over six years. Oh, and I bought it ex-rental for 130GBP. I suspect it had been in service for 3-5 years before I bought it.
Apart from a slightly flaky power button, it's still running fine. I suspect that it's actually a Nokia (who else makes TVs in Finland?)
That's certainly part of it, but as the consistency of production improves, manufacturers often find they're better off selling some proportion of the "good, fast" parts as "cheap, slow" parts in order to maximise their profits (If I have 50 quid in my pocket, I can either buy an AMD CPU, or a artificially crippled P4 badged as a Celeron. If that Celeron product didn't exist, Intel would probably not get any of my money, and their competitor would instead - a double whammy!)
That said, I don't overclock my gear because it's impossible for people like you and I to determine with any certainty why a "slow, cheap" part has been sold that way; because it failed the more advanced tests, or because it made more sense to market it that way (or because it was never even put through the advanced tests because this decision had already been made).
That's nothing. In the UK, basic broadband services start at 15GBP per month (about US$25.50), but the services from providers who are likely to still be around in 6 months time are usually 20GBP+ (about US$34). I'm paying 28.65GBP per month (about US$49) for ADSL at 512kbps/256kps at 50:1 contention, a/29 netblock, DNS and web hosting, and SMTP mail delivery.
UFOs are of course Unidentified Flying Ojects. They could be extra-terrestrial space craft, but they're more likely to just be some secret experimental (possibly exotically powered) aircraft that's gone wrong.
Given this, they could be powered by who-knows-what and carrying who-knows-what as cargo (possibly even piloted by space aliens too). With this in mind, I'd expect a chapter along the lines of "If you don't know what it is..."
I've had a bad file during a RH install. I noticed that Anaconda was retrying the rpm over and over, so I switched to the shell console, unmounted the CD, ejected it and replaced it with a good CD and remounted. The install continued as normal and I was left with a clean install. I'm not sure this will work every time and it's certainly not documented or supported, but it worked for me.
...but I think I'd prefer the flexibility of a Sony PlayStation Dual-Shock controller together with a USB adaptor. In the UK, the adaptors are easily available from Maplin for 7.99. Alternatively, they also do USB pads for 5.99 each.
I have no connections with Maplin, I'm just a satisfied customer.
To go out on a limb, there is something about this which reminds me of back when this country (Egypt) was under british colonial rule; the cotton was grown here, sold cheaply to European manufacturers, made into textiles, clothes, etc. there, and sold back to Egypt.
Despite the fact that, as a computer scientist, offshore outsourcing affects me directly, I'm pleased that the developing world is getting a slice of the wealth pie. Sadly, I fully expect that it won't last for long before their jobs are outsourced to somewhere cheaper again. If the folks in the developing world do manage to continue to build their power, influence and wealth, I just hope they'll be less exploitative of us then were were (and are) of them.
Don't get me wrong; I'm very happy that AMD continues to be a viable competitor to Intel, but the present mainstream AMD/IHV offerings don't suit my needs.
No, as I said, Intel provide sufficient documentation for stable, open drivers to be written for Linux, BSD, etc. Quality of documentation is a complaint substantially more common to SiS, nVidia, VIA, et al. As far as CPU/chipset compatibility goes, after a couple of early bad experiences, I wouldn't specify anything other an than Intel chipset to match an Intel CPU (unless I couldn't help it - a laptop, for instance).
If AMD had their own well-documented and reasonably-well performing and featureful chipset, then I'd be much more likely to use AMD processors. I gather this is the approach being taken with Opteron, so maybe I'll have an AMD box in the future. Alternatively, and I was thinking about this only the other day, if I wasn't planning on using AGP graphics, or the onboard IDE controller (i.e. my budget could stretch to a SCSI controller and devices and the machine was to run headless), I'd consider AMD then also.
Slashdot Mirror
MFM and GCR, respectively.
--
That's probably because the Amiga floppy controller wrote track-at-once, rather than secton-at-once but without either the controller or the trackdisk.device verifying that the entire track had been written correctly. Hence, if you updated a single sector on a track, the entire track would be re-written, and the "unmodified" tracks may get corrupted in the process.
There was a nice hack called TrackSalve which hacked the trackdisk.device so that it performed an automatic verify of tracks after writing. ISTR equivalent functionality may have been incorporated into trackdisk.device in 2.04/3.0+ Kickstarts, but before I started using TrackSalve, I used to frequently end up with corrupted diskette bitmaps (probably the most-rewritten track on an Amiga floppy).
Another, probably less significant factor is that the Amiga disk hardware wrote tracks with no gaps between sectors in order to get that extra 160KBytes. If a PC disk controller encountered an error in the inter-sector gaps, I doubt it would cause it many problems, but for Amigas, it increases the probability that an error will occur in an occupied cell of the disk.
--
I've always regarded that as a failure - the use didn't supply enough information for the program to do its job (hence a failure), but the program dumps some usage information as a convenience to the user. A quick test shows that GNU 'grep' returns 2 in such a case, so that's consistent.
You could argue that it failed in that it didn't do what the program was intended to do (e.g. encode mp3s), but you could also argue that the expected behaviour of the program, when provided zero parameters, is to display usage info, and it successfully did that.
I think you'd be in the minority with your latter argument.
What if, using whatever the proper syntax of the shell is, the user requests something like "encode all wave files in this directory" and there are zero wave files, and so the program encodes zero mp3s. Was that a success or a failure? It's a success in that nothing in the program broke, but it seems like perhaps something happened that the user isn't aware of, and perhaps the user should be informed.
My instinct is that that would depend on how the program is used. If the user needs to supply a list of files (e.g. *.wav before expansion by the shell), then if that list is null, the program should return an error. If, OTOH, the user needs to supply a path which is searched for files, then the program should exit(EXIT_SUCCESS) as long as that path exists and is readable.
What about if the user passes a "-h" parameter, asking for help, and the program displays the help. Was this a successful run of the program or a failure? It did exactly what the user asked, but it didn't fufill its main purpose, encoding mp3s in this example.
Again, convention indicates that a program displaying help if the user explicitly asks for it is successful operation. Some applications (e.g. GUI wrappers for command line applications) use '-h' and '--help' to find out what options are supported by the application they wrap in order to present appropriate controls in the GUI.
What if the user thinks "-h" means "highquality", but in fact the program interprets it as "display help"? The help blurb may be displayed, a success returned, and the files deleted.
OK, a potentially valid point, at last. But what if I think a GUI's "trashcan" icon actually represents a printer and I drag all my files to it hoping for them to be printed? There's a limit to how much you can do to protect the user from their own stupidity or ignorance.
I'm not advocating GUIs vs CLI or vice versa (I alternate between the two, depending on what I'm trying to get done), but I have a distate for Unix's return code system.
It's true that it's a shame that POSIX doesn't appear to define the commonly-accepted conventions I've described above, but this GNU libc manual page is a good start.
I'm interested to hear what would you propose instead of exit codes!
--
Yes, but a computer should save me, the user time and effort. In many examples (including this one), once the user has got the basic command line vocabulary and syntax, the command line will be more efficient for the user if they're performing a task at all regularly.
IMHO, about the only times a GUI wins are when you're performing some infrequent operation (such that you need to teach or remind yourself of syntax and options each time) and when you need to perform an operation on a bunch of files for which you can't easily come up with a regular expression. Even then, as your experience of regular expressions grows, it becomes easier to compose more elaborate regular expressions such that the CLI starts to win again in the latter scenario.
Second, if you're performing a command like this, especially one involving 'rm', you want to make damn sure there is no mistake. With GUI it's easier to have such a certainty.
It sounds as though you don't understand the '&&' operator - by using that, the OP has ensured that each file will only be removed if lame indicates (using its return code) that it completed successfully. Lame may lie, of course, but if you're concerned about that, then you won't want to automate this job at all. My experience indicates that it's extremely rare for a UNIX tool to lie in its return code value.
--
Red Hat/Fedora's GNOME panel is configured by default with a 'flotation ring' icon that starts 'yelp', a hypertext man/info reader.
I don't think you can really get much easier or more obvious than that.
--
--
Orange's "Where's my nearest?" function which uses the location of your current cell to find the nearest branch of XYZ Ltd, or the nearest XYZ restaurant/garage/whatever.
Googling for Linux compatibility when I see some neat toy at an attractive price.
Attempting to do some basic price checking. This is currently a weak spot, and I think there's a gap in the WAP arena for this.
Reading news headlines/stock prices when I'm in transit and without anything to read.
Checking train times.
--
The demand for food may not be going away, but if consumers' disposable income is reduced (say, by increasing interest payments on their debt mountains), then luxuries like going to a nice restaurant will be the first to go. I know this, because this is what I did when I needed to economise whilst running my own business.
I enjoy cooking, so I have considered going into catering, but the above, plus all the niggly things about it (e.g. staying behind 'til 2am to clean up ready for the next day), and a lack of catering trade experience thoroughly put me off. Also, in the same way as I wouldn't feel fulfilled selling bodged computer solutions, I wouldn't feel fulfilled selling cheap n' nasty junkfood (which McDonalds et al can probably do better and cheaper anyway).
--
--
Howzabout China? Or possibly even the western-style government-industry complexes that Eisenhower warned of if you're being as cynical as me.
--
--
--
I gave my dad my old 17" monitor, which was a Viglen Envy (probably MAG or something) that my employer had dropped down the stairs whilst moving. It's still working.
The only old monitors I don't still use are my PAL Philips 8852 from my Amiga days, and the 15" Iiyama which I bought with my first PC, back in 1995 for about 300GBP. That's the most expensive monitor I've ever bought!
--
--
Apart from a slightly flaky power button, it's still running fine. I suspect that it's actually a Nokia (who else makes TVs in Finland?)
--
That said, I don't overclock my gear because it's impossible for people like you and I to determine with any certainty why a "slow, cheap" part has been sold that way; because it failed the more advanced tests, or because it made more sense to market it that way (or because it was never even put through the advanced tests because this decision had already been made).
--
--
Also, SMP boards seem to be 2-3x the cost of UP boards before the cost of the CPUs.
[*] FSB speeds permitting. It does 400MHz and 533MHz FSB speeds, but not 800MHz.
--
Given this, they could be powered by who-knows-what and carrying who-knows-what as cargo (possibly even piloted by space aliens too). With this in mind, I'd expect a chapter along the lines of "If you don't know what it is..."
--
--
I have no connections with Maplin, I'm just a satisfied customer.
--
Probably because when the British Empire was around, it forbade our colonies from producing competing finished products in order to protect our national industries.
Despite the fact that, as a computer scientist, offshore outsourcing affects me directly, I'm pleased that the developing world is getting a slice of the wealth pie. Sadly, I fully expect that it won't last for long before their jobs are outsourced to somewhere cheaper again. If the folks in the developing world do manage to continue to build their power, influence and wealth, I just hope they'll be less exploitative of us then were were (and are) of them.
--
--
--
If AMD had their own well-documented and reasonably-well performing and featureful chipset, then I'd be much more likely to use AMD processors. I gather this is the approach being taken with Opteron, so maybe I'll have an AMD box in the future. Alternatively, and I was thinking about this only the other day, if I wasn't planning on using AGP graphics, or the onboard IDE controller (i.e. my budget could stretch to a SCSI controller and devices and the machine was to run headless), I'd consider AMD then also.
--