I've been using the Highpoint 1540 in production on linux for about 4 weeks now, with mediocre results.
The array switches to Disabled state at random, with no apparent cause. This happened twice yesterday, but not at all for the previous 8 days. I contacted Highpoint support and their advice was (1) make sure the BIOS version matches, and (2) check cables and connectors.
I'm using a beta version of their opensource driver which is not linked from their webpage.
I put it online at hpt374-opensource-v2.01-0718.tgz for any others who need v2 driver source rather than v1.
I'm running 2.4.21 with LVM. I did have the root filesystem on LVM under the Highpoint controller but had problems with extending it. So it is now under the inbuilt IDE controller, using software RAID and no LVM. I find my box is less fiddly to configure if the root filesystem is not LVM.
When the drivers set the array state to "Disabled" no more disk I/O is possible to those devices. A reboot is required. Strangely, the devices have never required resyncing after this problem.
At the subsequent reboot linux usually spends a few seconds replaying the filesystem journal (they're all EXT3 filesystems).
I have a theory that the Highpoint card (or driver) does not like sharing interrupts. Since the problems yesterday I have fiddled with the IRQ assignment and one problem that I had noticed (occasional ghost streaks on the CRT display, signifying contention on the video memory during a raster trace interval) has apparently disappeared. It may be that the Highpoint controller was sharing an interrupt with the display controller, making one of them not very happy. Thus, I'm cautiously optimistic that my problems may be cured.
In summary I can't really recommend the highpoint card for stable use. It's great to get a lot of IDE channels (e.g. using the quad-channel ATA card, and putting 2 devices per channel) and SATA is great for cabling drives, but there are obviously some driver issues which need to be worked out first.
A Redmond spokesman who declined to be identified confirmed today that Microsoft is designing the latest version of its popular Windows(tm) software without a cancel button.
"Apple removed 1 button from its mouse and used that as a selling point for years," exclaimed the spokesman, "now Microsoft's gone one better and taken out the cancel button. This will make operating a computer so much easier for users, by removing the tiresome need to make decisions about what your computer should do. Microsoft will make the right decision for you!"
Pundits expressed cautious optimism regarding this new move, saying "This will take the uncertainty out of worm propagation on the Internet. And that can only be considered a good thing."
It's great to look back in time like that. I like this quote particularly:
> Since these rules are based on 3-year steps, I'll look at the machine of
> 2003 (9 years from now) to make the math easier. According to these rules,
> the "average" machine of 2003 would have 1024MB RAM, and a 2.7GB disk.
Spot on for RAM but 2.7 gigs of disk won't go far today.
A good friend of mine runs a computer shop
and he told me today about his aim to sell
non-Windoze PCs. This is a direct quote from
his email to me:
M$ is putting a lot of pressure on PC manufacturers
to bundle Windows WITHOUT the option of removing it. I have had
arguments with our main computer supplier to get them to sell me
a M$ free computer. They say their records are being audited by M$
and if they can prove all systems were sold with Windows they get
a VERY big bonus.
Now if that's not a clearly anti-competitive practice, basically an agreement for restraint of trade, I don't know what is.
This is SCO's admission that Novell owns Unix System V, all revisions - that's what they mean by "SVRx", and SCO pays Novell 95% of the royalties. SCO gets to keep 5% as administrative agent.
It may also mean that, because SCO doesn't own the copyrights, they don't have standing in court to sue anybody who doesn't obtain a license. Presumably only Novell could do that, and they obviously don't want to.
I went through the "is coda right for me?" phase, and also
"is intermezzo right for me?" and also spent tens of hours researching
distributed filesystems and cluster filesystems online... my conclusion
is that the area is still immature, I will let the pot simmer for a
few more years (hopefully not many), and use NFS in the meantime.
My situation: desire for scalable and fault-tolerant distributed
filesystem for home use with minimal maintenance or balancing
effort. Emphasis on scalable, I want to be able to grow the
filesystem essentially without limit. I also don't want to
spend much time moving data between partitions. And last
but not least, the bigger the filesystem grows, the less
able I will be to back it up properly. I want redundancy so
that if a disk dies the data is mirrored onto another disk,
or if a server dies then the clients can continue to access
the filesystem through another server.
All that seems to be quite a tall order. I checked out coda, afs, PVCS,
sgi's xfs, frangipani, petal, nfs, intermezzo, berkeley's xfs, jfs, Sistina's
gfs and some project Microsoft is doing to build a serverless filesystem
based on a no-trust paradigm (that's quite unusual for Microsoft!).
Berkeley's xFS (now.cs.berkeley.edu) sounded the most
promising but it appears to be a defunct project, as their website has
been dead ever since I learned of it, and I expect the team never took
it beyond the "research" stage into "let's GPL this and transform it
into a robust production environment". Frangipani sounds interesting
also, and maybe a little more alive than xFS.
On the other hand coda, afs and intermezzo are all in active
development. afs IMHO suffered from kerberitis, i.e. once you
start using kerberos it invades everything and it has lots of
problems (which I read about on the openAFS list every day).
AFS doesn't support live replication (replication is done
in a batch sense) either.
CODA doesn't scale and doesn't have expected filesystem
functionality: for 80 gigs of server space I would require
3.2 gigs of virtual memory, and there's a limit to the size
of a CODA directory (256k) which isn't seen in ordinary filesystems.
There's also the full-file-download "feature". CODA
is good for serving small filesystems to frequently disconnected
clients but it is not good for serving the gigabyte AVIs which I
want to share with my family.
Intermezzo is a lot more lightweight than CODA and will scale a
lot better, but it's still a mirroring system rather than a
network filesystem. I might use that to mirror my remote server
where I just want to keep the data replicated and have write access
on both the server and the client, but it's again not a solution for
my situation.
The best thing about intermezzo is that it sits on top of a regular
filesystem, so if you lose intermezzo the data is still safe in
the underlying filesystem. CODA creates its own filesystem within
files on a regular filesystem, and if you lose CODA then the data
is trapped.
Frangipani is based on sharing data blocks, so like NFS it should be
suitable for distributing files of arbitrary size. I need to look at it
in a lot more detail; this is probably the right way to build a cluster
filesystem for the long haul. For the short term, Intermezzo is probably
the right way for a lot of people: it copies files from place to place
on top of existing filesystems.
What I did in the end:
new server (Celeron 1.3 GHz, 512 meg RAM)
2 x 80 gig IDE disks
Each IDE drive has 2 partitions (one small, one huge)
Each partition is RAID-1 mirrored with its partner on the other disk
The huge RAID partition is defined to Linux LVM (logical volume
manager)
Logical volumes are created within that for root,/home, etc...
All logical volumes are of type ext3 for recoverability.
The EMI website mentions HMV, and HMV's UK site points to a "shopfront" on od2.com.
I tried to use it, but it requires Windoze and Windoze Media Player, so I didn't get anywhere.
It seems that "some" of their content requires Windoze Media Player with DRM support to play. I wonder how EMI will fulfil their promise of "download to portable devices" -- unless they mean only those portable devices which implement Microsoft's Digital Restrictions.
It doesn't seem worth it to me, to buy music which becomes unplayable when I upgrade my computer. I have 20-year old LPs which would still be playable if I had a turntable, 10+ year old CDs which work fine whether I put them in the car, the DVD player, or the computer. Why should I consider buying music which will only play on a computer I am likely to replace entirely within 2 years?
In any case, it seems that it seems that EMI is still more interested in gouging the maximum amount of revenue from these works than in providing what customers really want. Linux users will not be supported.
As a sociologist, I really do need to call "random" people
Your need to get reliable data does not trump my right to not be disturbed by any you or any of the thousands of other sociologists who might want to call my number at random. Even though the chance is small that you in particular will choose my number to call, there are a lot more like you out there, doing basically the same kind of thing, which increases the probability that at least one of you is going to call me and ask me to participate in your survey, in which I am not the least bit interested.
I tend to agree with the other comments which say if you want to use my time for your purposes, then you can pay at my rate for it.
I think 1 year is quote adequate, or 2 years at most. None of this business about waiting for people to die... the world moves too fast for copyright lasting tens of years: produce it, make your money from it, move on.
My portable CD player was bought over 10 years ago (in Japan). It failed soon afterward. A non-geek would have had to throw it out, but I opened it up and found the problem was trivial (faulty diode in the power circuit, no idea why) and it has worked fine ever since.
Our 10-year-old TV screen now shows colour distortion, but the rest works fine. Our 10-year-old VCR has had to be repaired (dead heads) and I have had to crack it open several times for minor repairs also. It is showing wear in its moving parts.
The reason I don't replace them, or otherwise buy much in the way of consumer electronics these days, is the DRM problem. It's necessary to investigate each product carefully before purchasing, because the manufacturers don't exactly do out of their way to put "this is crippled crap" on the brochure. I was considering buying an MD player... until I found out about SCMS and that the players don't allow access to the raw bits on disc. I bought my DVD player with full knowledge about region-coding and macrovision - but then I had them disabled in the shop before taking delivery. In Australia it is now ILLEGAL for a shop to disable Macrovision (so it looks like I bought my DVD player at the right time!!)
The other reason I don't buy much consumer electronics is that the stuff is not well integrated yet. Behind the stereo looks like a rat's nest, so my first requirement is something to improve the cabling. Maybe a bus architecture?!? The gear doesn't "talk" to each other - when I turn on the TV, the stereo should turn on too, and set its input to TV. My VCR has a clock which loses its setting every time we have a power outage, plus I have to manually reset it twice a year for Daylight Saving. Why can't it self-synchronise on a timestamp from the TV signal, for example?
I don't want to buy another lemon like the Sony combined TV/VCR we got a few years ago. Not only does it have mono sound only (my fault for not checking enough) but its internal clock loses time on power loss (as above) and it cannot be reset while there are recordings programmed! That's one stupid device.
As for computer equipment (which to me is quite a separate thing from consumer electronics) I have found the quality is steadily improving over time. When I buy a card these days generally it comes with adequate documentation, not like a few years ago. These days, motherboards usually fit into cases (I've bought some where I had to start doing metalwork on the case just to get the mobo in). Various cards are usually compatible with each other nowadays (not like the SCSI card I had which couldn't be used with the ethernet card). Sure, hard disk warranties have gone down, and maybe they are more prone to failure than before - but they have always been prone to failure, and it has always been important to keep regular backups. Paradoxically, a dead CPU or mobo doesn't matter much because your important data is on the disc, yet the CPU is ultimately more reliable due to no moving parts.
So in general I don't think quality has gone down, or not much. My expectations have gone up a lot. I feel that manufacturers aren't paying attention to integrating products, at least in Australia. In Japan you can buy watches which self-synchronise off a low frequency AM radio signal.
I've been looking, for several years, for a digital clock radio which has a _digital_ tuning mechanism, as opposed to the ones which tune a capacitor and use string to pull an indicator across a frequency indicator. I can't understand why such a simple requirement is completely ignored by the manufacturers. It must be cheaper to produce a digital tuner than one containing strings and pulleys, at least. Actually I found one about 18 months ago but the price was well out of my range, and I was in a specialty store for "geek toys" at the time; I have never seen one in any of the usual department stores where the bulk of the population buy their electronics.
Both sets of calculations, which ran to over 30 pages, were based on an idealised shoe. For example, the eyelets are perfectly aligned, and the shoe exists only in one plane. The proofs also ignore certain physical properties, such as the friction exerted by the lace on the eyehole.
It sounds like the recovery team had only the
finished, "executable" version of the system to work with. Using an emulator allowed them to
use the content without really understanding
the data structures or algorithms within. And
therein lies the problem. By making the "binary" work, they have doomed (heh) themselves to continue to keep that binary
working until somebody gets the right idea,
and converts the system into "source code"
which can be used with any modern technology.
As the GNU project says, "source code" is the preferred form for modification of a work. For this project, the source code for the display program might be BASIC or assembler, but that's not important. What's important is the text/image/video/audio content, and the source form for that content might be XML PNM (no lossy compression), uncompressed AVI and WAV files.
Converting the original, BBC-Micro specific
program into a modern source format will eliminate the need for a special or unique system to access that content.
Furthermore, distribution costs on the Internet approach zero, so that work can be
made widely available to everybody, not just a few schools or visitors to a museum.
Over time our popular formats such as JPEG and AVI files will become obsolete, so
the work must be converted into that newer
form in future, possibly ad-infinitum. At least those future conversions will occur from one well-known and popular format into another.
The software and hardware needed to access the Domesday discs is to be deposited at the Public Record Office once the project is completed.
They haven't really learned from their efforts, have they?
So here's the new reason to use open source:
It is important to preserve our digital heritage, and using source code is the best
means we have of making works accessable and
compatible with the computers of the future.
In one initiative, dubbed Fake Tourist, 60 trained actors and actresses will haunt tourist attractions such as the Empire State Building in New York and the Space Needle in Seattle.
I can't imagine that an already-nervous USA
is going to be too happy to have a lot of
people behaving strangely around famous
tourist attractions. The mind boggles at
what might happen if the local security guards
get nervous.
I don't see why. *smile* To me it sounds like Microsoft would be satisfied if any OpenGL technology developed using their "Intelectual Property" was GPL'd.
What if it was the other way around? Microsoft could not use OpenGL technology if it were GPLed, because that would then force Microsoft to GPL their own derivatives. So Microsoft may argue from their position of
power that OpenGL may not be released as GPL... which might kill OpenGL by stealth.
IMHO the best keyboard in the world is the genuine IBM buckling-spring keyboard as used in IBM PS/2s.
I've tried many different keyboards, and nothing beats the IBM. The reason is the positive feedback as soon as the key registers. Other keyboards are mushy - they have no "feel" when the key is pressed, or very little, but the IBM keyboard provides increased resistance just before the key fires, and decreased resistance after. I have done tests on other keyboards and found bad behaviour like the key fires without feeling any feedback.
Sure the IBM is noisier than other keyboards but the feel makes a lot of difference to an impatient geek who needs to get those keystrokes entered ASAP! I get a good feel for if I'm typing the right thing whether I am looking at the screen or the keyboard or somewhere else entirely.
The Steam Engine didn't deliver 2+ gigs of pr0n
into my newsserver every day.
Dropping 16 users at a time
on
Pet Bugs?
·
· Score: 2, Interesting
I discovered that the network concentrators at
Uni would die on any sequence of 4 "n"s in a
row (i.e. "nnnn") in the same packet. I was trying to read a man page and puzzled why
the system kept dying before I got to the end.
Eventually I redirected the man page to a
file and used something like an octal dump to
find the sequence without displaying it on the
screen.
I then tested, typed "nnnn" and down went the
network concentrator. Unfortunately that killed the other 15 users as well...
I reported this bug to the University
Computer Centre who either didn't believe me
or took no apparent action, but sometime later they upgraded to a different brand of gear for the campus WAN. I also reported it on comp.risks. I can find no other documented cases of this bug on the Net using a google
search.
What I'd like to know is, why was it encrypted in the first place? An archive of 16,000 books of Norwegian history doesn't sound like sensitive material, unless...
... unless the Norwegians actually discovered space travel around the year 600 AD and have been communicating with aliens ever since...
Yes, but the programmers and designers do not! In
a previous job I inherited a large system built
principally on SQL. The queries were sometimes up
to a full page of convoluted SQL. Even those
cow-orkers most familiar with the system were at a
loss to understand what a lot of it did.
I'm
sure formal proofs of correctness were not possible and probably never entered the heads
of the implementors.
The system behaved inconsistently and exhibited
different errors each month.
The code was buggy, but the actual erroneous statements were not obvious. Maybe it was something subtle like a missing row in an 8-table join, or an unexpected NULL value in the row for
the third previous invoice.
The mere fact of
this unreliable behaviour coupled with the
inability of senior staff to pinpoint the erroneous statements leads me to believe that
there's a more fundamental problem at work here than sloppy design or bad implementation. The conclusion is that the SQL language itself and by
implication its relational calculus underpinnings, are not suitable for programming certain types of systems.
Relational databases have their benefits when the data and the access modes fit neatly into the relational model. Over-normalisation of data is a
sign though, that the relational model is breaking down in that instance.
Hierarchical is a much better fit for an object-based data model: "this IP address is a host, and it's running these services; that IP address is a router, and its connections are..."
I was telling an ex-cow-orker about IBM's IMS hierarchical database recently, how the access modes facilitate more correct programming ("get next object; do something with it; update and get following object") and easier access to related data ("get the next object contained within this object"). Although he grew up on PostgreSQL his response was "cooool!".
I read one time on here that some guy refused to open a document someone had sent him at work because it wasn't in an "open format."
I do that all the time. It's partly a matter of
principle, and partly simple pragmatism.
These are usually Micro$oft Word documents, but sometimes also Excel spreadsheets
or PowerPoint presentations.
On Principle:Documents which are intended to have some long
lifetime (like project plans, company policies,
systems documentation) should be properly change-managed. That doesn't mean they should
live on some employee's Windoze box and
in a proprietary binary format which is known for
Virus transmission
Leakage of deleted information
Any other old crap which happens to be in RAM when the document is saved
Proper
change management means, as a minimum, the document source is
maintained on a CVS server, as readable text (i.e. plain text or marked up in TeX, HTML, XML, SGML or some other readable language) and able to be analysed by diff.
Pragmatism: I use Unix at work and at home, and I don't use Windows. Windows hurts my productivity too much. I'm not about to spend
time to setup a Windows box or Wine or whatever
and install Micro$oft's bloated applications just so I can read somebody's email with different fonts (*) or their improperly change-managed document. Since the document isn't really revisable by me, I'll happily receive a PostScript or PDF rendering which I can view or
print, and if I need to make changes, I'll use a
red pen on paper.
(*) Yes, this really happened. I was chastised because somebody sent an email where they had marked up previous text in a different
colour or bold, rather than using the Internet
standard quoting convention of ">" prefix.
Slashdot Mirror
The array switches to Disabled state at random, with no apparent cause. This happened twice yesterday, but not at all for the previous 8 days. I contacted Highpoint support and their advice was (1) make sure the BIOS version matches, and (2) check cables and connectors.
I'm using a beta version of their opensource driver which is not linked from their webpage. I put it online at hpt374-opensource-v2.01-0718.tgz for any others who need v2 driver source rather than v1.
I'm running 2.4.21 with LVM. I did have the root filesystem on LVM under the Highpoint controller but had problems with extending it. So it is now under the inbuilt IDE controller, using software RAID and no LVM. I find my box is less fiddly to configure if the root filesystem is not LVM.
When the drivers set the array state to "Disabled" no more disk I/O is possible to those devices. A reboot is required. Strangely, the devices have never required resyncing after this problem.
At the subsequent reboot linux usually spends a few seconds replaying the filesystem journal (they're all EXT3 filesystems).
I have a theory that the Highpoint card (or driver) does not like sharing interrupts. Since the problems yesterday I have fiddled with the IRQ assignment and one problem that I had noticed (occasional ghost streaks on the CRT display, signifying contention on the video memory during a raster trace interval) has apparently disappeared. It may be that the Highpoint controller was sharing an interrupt with the display controller, making one of them not very happy. Thus, I'm cautiously optimistic that my problems may be cured.
In summary I can't really recommend the highpoint card for stable use. It's great to get a lot of IDE channels (e.g. using the quad-channel ATA card, and putting 2 devices per channel) and SATA is great for cabling drives, but there are obviously some driver issues which need to be worked out first.
Pundits expressed cautious optimism regarding this new move, saying "This will take the uncertainty out of worm propagation on the Internet. And that can only be considered a good thing."
It's great to look back in time like that. I like this quote particularly:
> Since these rules are based on 3-year steps, I'll look at the machine of> 2003 (9 years from now) to make the math easier. According to these rules,
> the "average" machine of 2003 would have 1024MB RAM, and a 2.7GB disk.
Spot on for RAM but 2.7 gigs of disk won't go far today.
Maybe SCO will soon claim that GCC contains their secret intellektval pr0perty and ... you can guess what happens next ...
A good friend of mine runs a computer shop and he told me today about his aim to sell non-Windoze PCs. This is a direct quote from his email to me:
Now if that's not a clearly anti-competitive practice, basically an agreement for restraint of trade, I don't know what is.
It may also mean that, because SCO doesn't own the copyrights, they don't have standing in court to sue anybody who doesn't obtain a license. Presumably only Novell could do that, and they obviously don't want to.
Why not stick with NFS for the time being?
I went through the "is coda right for me?" phase, and also "is intermezzo right for me?" and also spent tens of hours researching distributed filesystems and cluster filesystems online ... my conclusion
is that the area is still immature, I will let the pot simmer for a
few more years (hopefully not many), and use NFS in the meantime.
My situation: desire for scalable and fault-tolerant distributed filesystem for home use with minimal maintenance or balancing effort. Emphasis on scalable, I want to be able to grow the filesystem essentially without limit. I also don't want to spend much time moving data between partitions. And last but not least, the bigger the filesystem grows, the less able I will be to back it up properly. I want redundancy so that if a disk dies the data is mirrored onto another disk, or if a server dies then the clients can continue to access the filesystem through another server.
All that seems to be quite a tall order. I checked out coda, afs, PVCS, sgi's xfs, frangipani, petal, nfs, intermezzo, berkeley's xfs, jfs, Sistina's gfs and some project Microsoft is doing to build a serverless filesystem based on a no-trust paradigm (that's quite unusual for Microsoft!).
Berkeley's xFS (now.cs.berkeley.edu) sounded the most promising but it appears to be a defunct project, as their website has been dead ever since I learned of it, and I expect the team never took it beyond the "research" stage into "let's GPL this and transform it into a robust production environment". Frangipani sounds interesting also, and maybe a little more alive than xFS.
On the other hand coda, afs and intermezzo are all in active development. afs IMHO suffered from kerberitis, i.e. once you start using kerberos it invades everything and it has lots of problems (which I read about on the openAFS list every day). AFS doesn't support live replication (replication is done in a batch sense) either.
CODA doesn't scale and doesn't have expected filesystem functionality: for 80 gigs of server space I would require 3.2 gigs of virtual memory, and there's a limit to the size of a CODA directory (256k) which isn't seen in ordinary filesystems. There's also the full-file-download "feature". CODA is good for serving small filesystems to frequently disconnected clients but it is not good for serving the gigabyte AVIs which I want to share with my family.
Intermezzo is a lot more lightweight than CODA and will scale a lot better, but it's still a mirroring system rather than a network filesystem. I might use that to mirror my remote server where I just want to keep the data replicated and have write access on both the server and the client, but it's again not a solution for my situation.
The best thing about intermezzo is that it sits on top of a regular filesystem, so if you lose intermezzo the data is still safe in the underlying filesystem. CODA creates its own filesystem within files on a regular filesystem, and if you lose CODA then the data is trapped.
Frangipani is based on sharing data blocks, so like NFS it should be suitable for distributing files of arbitrary size. I need to look at it in a lot more detail; this is probably the right way to build a cluster filesystem for the long haul. For the short term, Intermezzo is probably the right way for a lot of people: it copies files from place to place on top of existing filesystems.
What I did in the end:
The way it works is tha
The EMI website mentions HMV, and HMV's UK site points to a "shopfront" on od2.com.
I tried to use it, but it requires Windoze and Windoze Media Player, so I didn't get anywhere.
It seems that "some" of their content requires Windoze Media Player with DRM support to play. I wonder how EMI will fulfil their promise of "download to portable devices" -- unless they mean only those portable devices which implement Microsoft's Digital Restrictions.
It doesn't seem worth it to me, to buy music which becomes unplayable when I upgrade my computer. I have 20-year old LPs which would still be playable if I had a turntable, 10+ year old CDs which work fine whether I put them in the car, the DVD player, or the computer. Why should I consider buying music which will only play on a computer I am likely to replace entirely within 2 years?
In any case, it seems that it seems that EMI is still more interested in gouging the maximum amount of revenue from these works than in providing what customers really want. Linux users will not be supported.
Your need to get reliable data does not trump my right to not be disturbed by any you or any of the thousands of other sociologists who might want to call my number at random. Even though the chance is small that you in particular will choose my number to call, there are a lot more like you out there, doing basically the same kind of thing, which increases the probability that at least one of you is going to call me and ask me to participate in your survey, in which I am not the least bit interested.
I tend to agree with the other comments which say if you want to use my time for your purposes, then you can pay at my rate for it.
The Internet has shown that the best way to protect a work is to release it on the Net and allow it to be downloaded, duplicated, mirrored etc. etc.
Locking those recordings in a big mountain-side vault, or putting them on a computer in a building I'll never visit, is not "making them available".
I think 1 year is quote adequate, or 2 years at most. None of this business about waiting for people to die ... the world moves too fast for copyright lasting tens of years: produce it, make your money from it, move on.
My portable CD player was bought over 10 years ago (in Japan). It failed soon afterward. A non-geek would have had to throw it out, but I opened it up and found the problem was trivial (faulty diode in the power circuit, no idea why) and it has worked fine ever since.
... until I found out about SCMS and that the players don't allow access to the raw bits on disc. I bought my DVD player with full knowledge about region-coding and macrovision - but then I had
Our 10-year-old TV screen now shows colour distortion, but the rest works fine. Our 10-year-old VCR has had to be repaired (dead heads) and I have had to crack it open several times for minor repairs also. It is showing wear in its moving parts.
The reason I don't replace them, or otherwise buy much in the way of consumer electronics these days, is the DRM problem. It's necessary to investigate each product carefully before purchasing, because the manufacturers don't exactly do out of their way to put "this is crippled crap" on the brochure. I was considering buying an MD player
them disabled in the shop before taking delivery. In Australia it is now ILLEGAL for a shop to disable Macrovision (so it looks like I bought my DVD player at the right time!!)
The other reason I don't buy much consumer electronics is that the stuff is not well integrated yet. Behind the stereo looks like a
rat's nest, so my first requirement is something to improve the cabling. Maybe a bus architecture?!? The gear doesn't "talk" to each other - when I turn on the TV, the stereo should turn on too, and set its input to TV. My VCR has a clock which loses its setting every time we have a power outage, plus I have to manually reset it twice a year for Daylight Saving. Why can't it self-synchronise on a timestamp from the TV signal, for example?
I don't want to buy another lemon like the Sony combined TV/VCR we got a few years ago. Not only does it have mono sound only (my fault for not checking enough) but its internal clock loses time on power loss (as above) and it cannot be reset while there are recordings programmed! That's one stupid device.
As for computer equipment (which to me is quite a separate thing from consumer electronics) I have found the quality is steadily improving over time. When I buy a card these days generally it comes with adequate documentation, not like a few years ago. These days, motherboards usually fit into cases (I've bought some where I had to start doing metalwork on the case just to get the mobo in). Various cards are usually compatible with each other nowadays (not like the SCSI card I had which couldn't be used with the ethernet card). Sure, hard disk warranties have gone down, and maybe they are more prone to failure than before - but they have always been prone to failure, and it has always been important to keep regular backups. Paradoxically, a dead CPU or mobo doesn't matter much because your important data is on the disc, yet the CPU is ultimately more reliable due to no moving parts.
So in general I don't think quality has gone down, or not much. My expectations have gone up a lot. I feel that manufacturers aren't paying attention to integrating products, at least in Australia. In Japan you can buy watches which self-synchronise off a low frequency AM radio signal.
I've been looking, for several years, for a digital clock radio which has a _digital_ tuning mechanism, as opposed to the ones which tune a capacitor and use string to pull an indicator across a frequency indicator. I can't understand why such a simple requirement is completely ignored by the manufacturers. It must be cheaper to produce a digital tuner than one containing strings and pulleys, at least. Actually I found one about 18 months ago but the price was well out of my range, and I was in a specialty store for "geek toys" at the time; I have never seen one in any of the usual department stores where the bulk of the population buy their electronics.
First, postulate a spherical foot ...
As the GNU project says, "source code" is the preferred form for modification of a work. For this project, the source code for the display program might be BASIC or assembler, but that's not important. What's important is the text/image/video/audio content, and the source form for that content might be XML PNM (no lossy compression), uncompressed AVI and WAV files.
Converting the original, BBC-Micro specific program into a modern source format will eliminate the need for a special or unique system to access that content.
Furthermore, distribution costs on the Internet approach zero, so that work can be made widely available to everybody, not just a few schools or visitors to a museum.
Over time our popular formats such as JPEG and AVI files will become obsolete, so the work must be converted into that newer form in future, possibly ad-infinitum. At least those future conversions will occur from one well-known and popular format into another.
They haven't really learned from their efforts, have they?
So here's the new reason to use open source: It is important to preserve our digital heritage, and using source code is the best means we have of making works accessable and compatible with the computers of the future.
I can't imagine that an already-nervous USA is going to be too happy to have a lot of people behaving strangely around famous tourist attractions. The mind boggles at what might happen if the local security guards get nervous.
What if it was the other way around? Microsoft could not use OpenGL technology if it were GPLed, because that would then force Microsoft to GPL their own derivatives. So Microsoft may argue from their position of power that OpenGL may not be released as GPL ... which might kill OpenGL by stealth.
I guess the lab was out of lawyers that day.
IMHO the best keyboard in the world is the genuine IBM buckling-spring keyboard as used in IBM PS/2s.
I've tried many different keyboards, and nothing beats the IBM. The reason is the positive feedback as soon as the key registers. Other keyboards are mushy - they have no "feel" when the key is pressed, or very little, but the IBM keyboard provides increased resistance just before the key fires, and decreased resistance after. I have done tests on other keyboards and found bad behaviour like the key fires without feeling any feedback.
Sure the IBM is noisier than other keyboards but the feel makes a lot of difference to an impatient geek who needs to get those keystrokes entered ASAP! I get a good feel for if I'm typing the right thing whether I am looking at the screen or the keyboard or somewhere else entirely.
Shouldn't this one be listed in "The Almighty Buck"??
Yes, very different.
The Steam Engine didn't deliver 2+ gigs of pr0n into my newsserver every day.
I discovered that the network concentrators at Uni would die on any sequence of 4 "n"s in a row (i.e. "nnnn") in the same packet. I was trying to read a man page and puzzled why the system kept dying before I got to the end. Eventually I redirected the man page to a file and used something like an octal dump to find the sequence without displaying it on the screen.
I then tested, typed "nnnn" and down went the network concentrator. Unfortunately that killed the other 15 users as well...
I reported this bug to the University Computer Centre who either didn't believe me or took no apparent action, but sometime later they upgraded to a different brand of gear for the campus WAN. I also reported it on comp.risks. I can find no other documented cases of this bug on the Net using a google search.
What I'd like to know is, why was it ...
... unless the Norwegians actually discovered ...
encrypted in the first place? An archive
of 16,000 books of Norwegian history doesn't
sound like sensitive material, unless
space travel around the year 600 AD and have
been communicating with aliens ever since
Yes, but the programmers and designers do not! In a previous job I inherited a large system built principally on SQL. The queries were sometimes up to a full page of convoluted SQL. Even those cow-orkers most familiar with the system were at a loss to understand what a lot of it did.
I'm sure formal proofs of correctness were not possible and probably never entered the heads of the implementors. The system behaved inconsistently and exhibited different errors each month. The code was buggy, but the actual erroneous statements were not obvious. Maybe it was something subtle like a missing row in an 8-table join, or an unexpected NULL value in the row for the third previous invoice.
The mere fact of this unreliable behaviour coupled with the inability of senior staff to pinpoint the erroneous statements leads me to believe that there's a more fundamental problem at work here than sloppy design or bad implementation. The conclusion is that the SQL language itself and by implication its relational calculus underpinnings, are not suitable for programming certain types of systems.
Relational databases have their benefits when the data and the access modes fit neatly into the relational model. Over-normalisation of data is a
..."
sign though, that the relational model is breaking down in that instance.
Hierarchical is a much better fit for an object-based data model: "this IP address is a host, and it's running these services; that IP address is a router, and its connections are
I was telling an ex-cow-orker about IBM's IMS hierarchical database recently, how the access modes facilitate more correct programming ("get next object; do something with it; update and get following object") and easier access to related data ("get the next object contained within this object"). Although he grew up on PostgreSQL his response was "cooool!".
I do that all the time. It's partly a matter of principle, and partly simple pragmatism.
These are usually Micro$oft Word documents, but sometimes also Excel spreadsheets or PowerPoint presentations.
On Principle:Documents which are intended to have some long lifetime (like project plans, company policies, systems documentation) should be properly change-managed. That doesn't mean they should live on some employee's Windoze box and in a proprietary binary format which is known for
Proper change management means, as a minimum, the document source is maintained on a CVS server, as readable text (i.e. plain text or marked up in TeX, HTML, XML, SGML or some other readable language) and able to be analysed by diff.
Pragmatism: I use Unix at work and at home, and I don't use Windows. Windows hurts my productivity too much. I'm not about to spend time to setup a Windows box or Wine or whatever and install Micro$oft's bloated applications just so I can read somebody's email with different fonts (*) or their improperly change-managed document. Since the document isn't really revisable by me, I'll happily receive a PostScript or PDF rendering which I can view or print, and if I need to make changes, I'll use a red pen on paper.
(*) Yes, this really happened. I was chastised because somebody sent an email where they had marked up previous text in a different colour or bold, rather than using the Internet standard quoting convention of ">" prefix.