Also spell check and let an unemployed English major review it.
Some of the people with the worst spelling and grammar I have met in professional life were English graduates. For that matter, they were also advertising copywriters.
Bill Gates has led one of the planets most profitable companies for over a decade. He deserves a Knighthood.
I understand the first sentence above. I understand the second sentence. Why does the first demonstrate the second, though?
Other future Knights to consider (Assuming the Monarchy lasts long enough); "Lord Linus" For contributions to science. "Sir Tiger" For contribution to sport. "Lady Margaret" for contribution to politics.
I'm positing this comment about the article here because the handling of apostrophes and quotes within the Nine Nines.org comment handling is all fubar. Anyway, the article says...
[mid-level managers]...
fall back on corporate speak when addressing a crowd ("middleware," "enterprise").
Perhaps the reviewer doesn't understand - middleware is real. It's an actual type of product, that does a genuinely useful job. The only synonymn for "middleware" that is really appropriate which I guess you wouldn't think is "corporate speak" is "glue", but these days it tends to understate the level of functionality in the middleware ("glue" was more appropriate when middleware was just stuff like basic Websphere MQ). I suppose that regular geeks just don't often come across middleware much because it doesn't do much for smaller (or home) installations. Middleware becomes important when you have to take a set of half a dozen applications and make them interoperate. The larger your organisation is, the more important middleware is. You can pay anywhere between $30,000 and $5,000,000 for a middleware system (just for the license, not including the cost of actually installing, customising and using it), so people are very careful about what they spend their money on.
In fact, the jargon term for an organisation large enough to actually need middleware is - "enterprise". They're often not referred to as companies because (i) they may not be commercial organisations and (ii) they're often large enough to include several organisations that are large companies in their own right.
So, perhaps the words "enterprise" and "middleware" seemed to the reviewer like vague corporate fluff words simply becuase they don't correspond to things in his/her world-view. However, they're real concepts and useful words.
So, someone makes a change to an existing OSS filter, MS can say, "Hey! You used the details of our patent to further your work, pay up or we'll....(insert crushing legal threat here)"
Which means it's going to be much,much harder to get an OSS filter for the next version(s) of MS Office, as you'll have to be pretty strict with the reverse-engineering to ensure you don't wind up in the courts defending your work against a bunch of attack lawyers from a billion-dollar company.
I think you have misunderstood the nature of patents. If you improve the OSS filter without ever reading he text of the patent, Microsoft would still be able to sue you. The patent gives them exclusive rights to use the methods and techniques covered by the patent. It doesn't matter how you came up with your code; if it uses the same method, it infringes.
I'd like to know, with the growing list of certs for linux which ones are worth it?
But the EAL certifications cover the security of the system itself. Those certifications are applied to computer system products, not to people...
There's a description of the EAL certification levels in the at the NIST site which is linked to from the top-level article. The point about this certification from Linux's point of view is that it allows it to be cinsidered for various sorts of Government deployment, which often require EAL certification to a certain level.
I understand that the Fortran compiler may be better than free alternatives.
The Watcom FORTRAN compiler (which I used in 1990) has an auspicious ancestor, the WATFIV compiler from the University of Waterloo. They have a history page for it there.
... but it's not entirely unreasonable for SCO to state (and then attempt to demonstrate) that ownership of the copyrights is required by them in order to defend against apparent illegal copyright infringment from a third party.
I don't think that's true, because it's the copyright owner who is damaged by infringment of the copyright, and so if SCO is not already the owner it isn't harmed by the infringement and therefore has no need to own the copyright in order to pursue a remedy.
On the other hand, if their point is that IBM's actions in relation to the material they have licensed prejudices SCO's business then they would need to ask Novell to take action. It might make sense for the contract to cover this possibility, but I haven't read it and so I don't know if it's there or not.
SCO could win this in several ways and no, it doesn't have to be inbred juries. The GPL has never been tested in court, I haven't seen anything indicating that this is 100% reliable.
A common interpretation of this fact is that the GPL is strong enough (remember it's not a licence that anybody is forced to adopt, it's not like an EULA) that none of the companies that have been caught to date have gone all the way to court when challenged by the FSF - they've all settled.
In any case though, the SCO case isn't really about the GPL, it's about their allegation that IBM has done things thay they had contractually agreed not to do or were otherwise prohibited from doing.
If they did, the Linux community would make sure that the offending code wasn't in the next kernal [sic!] release (which would probably be all of a week in coming) and then SCO could only go after users for past use of their code.
If SCO wants to be awarded damages for this, then they have a problem. In order to get a good award for damages you have to be able to show that you took action promtply to make the problem stop, as opposed to waiting longer in order to inflate your damages claim. Hence according to this doctrine SCO should indicate immediately the specific nature and identity of the problematic material in order to limit the damage they're suffering from.
On the other hand of course they may be able to counter this point on the basis that the code is already available freely and it would be in effect impossible to force destruction of all the available copies of the offending code, and so they're not doing further damage by keeping quiet about exactly what code is tainted.
The article states that all DVD players are constructed within China. Certainly mine was. However, there are some high-end manufacturers that assemble the final product outside China (no doubt at least partly from components manufactured inside China). Of these, the first one to come to mind is the legendary HiFi manufacturer, Linn (see this article about how their factory works). Of course, that makes them much more expensive than the stuff assembled in China. Take for example their UNIDISK 2.1 player, which plays every disc format (e.g. CD, SACD, DVD-Audio) and could well be the best-sounding player available anywhere. But it costs $8064 (more if you want the silver finish) rather than $30.
There are other UK manufacturers who almost certainly assemble their own DVD players. These include
Arcam and
Roksan.
I've used manual-focus Pentax cameras for about 15 years. I've been very happy, but I used to get a proportion of poorly-focussed exposures. That was laziness, but it has to be said that the split-prism focussing mechanism often works poorly with small aperture lenses. I borrowed someone's short Pentax zoom and was very impressed; the pictures were coming out much more visually pleasing than the ones I had taken with my own (third-party Pentax-fit) lenses.
This convinced me that what I really needed to do was to have the option of auto-focus for convenience but that I also needed to make more sensible choices about who I bought the lenses from (the Pentax own-bran lenses are very good indeed, far, far better than the 'generic' lenses I was using). Since I would have to replace all my existing lenses anyway, over time, my existing investment in Pentax KA-fit third-party lenses was moot. Therefore I decided to switch to either Nikon or Canon (although Pentax probably has the best availability of second-hand lenses at good prices, there is a wider selection of new lenses for Nikon and Canon cameras).
What it came down to in the end was that I tried the Nikon and Canon cameras out and chose the one whose user interface I preferred. While my choice was not without drawbacks (the camera I have ended up with won't accept manual-focus lenses) I'm happy with it. My photographs have improved, certainly.
In summary, I would say that I've found auto-focus to be very useful, and I'd also advise you to buy the lenses made by your camera's manufacturer (e.g. buy Pentax, Canon or Nikon lenses and try to avoid buying third-party 'equivalent' products).
I'll buy a digital camera eventually, but I'm waiting until the cameras with full-size sensors are affordable (they exist currently but are too expensive for me to buy).
Furthermore, since MS-DOS didn't provide a memory allocator, it's stupid to say that MS-DOS can't address non-contiguous memory.
The point is that the way you determine how much RAM there is in the box is to use a BIOS call that returns the number of accessible paragraphs in the first contiguous bit of RAM. There's no way for it to tell you about some other large lump of RAM which lives up there beyond the address of the monochrome display, for example.
The Microcosm system had this feature (hyperlinks in videos) in 1993, possibly earlier. It even worked with videodisks...
Not by the way that I really rated Microcosm, it was really quite buggy and was overtaken by HTML, which of course turned out to be the category-killer in the hypertext arena.
I would love to hear people who used to work for Novell weigh in on the timeline. I know that Linux had SMP on certain limited motherboards VERY early on and as early as v0.27, 05 may 1998 [tldp.org], the new motherboards were being added to the already growing list of Linux SMP platforms....
That's v0.27 of the Linux-SMP HOWTO, not the Linux kernel. The release date of that version of the HOWTO was 05 may 1998.
Linux 2.0.33 was released on 16 Dec 1997.
Linux 2.0.34 was released on 03 Jun 1998.
Linux 2.1.99 was released on 20 Apr 1998.
Linux 2.1.100 was released on 07 May 1998.
It looks to me as if SMP was introduced to Linux in kernel version 1.3.26 (13 Sep 1995). The patch is
here.
Much of the material we're talking about has literally deteriorated due to the passage of time. No such deterioration takes place in the digital age.
Not as such, no, but there are equivalent processes. For example, there is a version of the Linux kernel, released by Linus, of which there is no known remaining copy. References to it by version number exist, but nobody can find the thing itself or a patch for it. I forget which version it was, but some years ago someone collected all the old kernel tarballs to issue them on a "historic record" style CD-ROM and was unsuccessfully trying to track it down.
I know finding one of the old pre-amps from Radio Shack is probably out of the question - does anyone else remember the little black boxes with RCA in and RCA out jacks, a screw terminal for the ground wire that also comes out of turn-tables and a power cord?
I always use one with my amp, because it's better than the phono stage in my amp. They're called "phono stages" or "phono amplifiers" usually.
The one I use is a Musical Fidelity X-LPS, which I find works very well. You can plug it into your amplifier (which is how I use it for normal listening) and then connect your PC to the tape or MD output jacks of the amp to do the recording, or you could do it the other way and plug the X-LPS line-level outputs directly into the PC (I do it this way).
The critical thing when using Gramofile is to get the recording level right (this is the "igain" control in your audio mixer). If you get it wrong, you will saturate the A/D converter's input. This only needs to happen very occasionally to ruin the recording, and it normally happens at sractches. However, Gramofile, while it does a good job with scratches generally, can't deal so effectively with the aftereffects of saturating the soundcard's input (you tend to get a kind of echo of the crackle). So, even if it tells you that "0.0%" of the samples were at full-scale, check the actual number of full-scale samples.
The best way to do this in my opinion is to launch the ReZound audio editor. This will colour-code the full-scale regions of the sample file, enabling you to identify at a glance if you need to re-record.
Lastly, I suppose this is a rather obvious point, but the result of doing this will never be as good as the results you get listening to the original record. You can only lose information, not recover it. So, if you really care about those LPs, invest in a good turntable and cartridge! This doesn't have to be so expensive. I bought a second-hand LP12 earlier this year for less than 1/3 the price of a new one (obviously to do justice to it I will need to get a much better sound card than the one that comes on my PC's motherboard).
Try "hard SF" rather than hacker SF
on
A Good Summer Read?
·
· Score: 2, Informative
I'm talking about anything by Arthur Clarke, Stanislaw Lem (his book The Cyberiad is pretty hackish in nature and very good). Also David Brin (e.g.
Sundiver)
Less "hard" SF to consider -
The Stars My Destination, by Alfred Bester, Nova by Samuel R. Delany. Maybe even
Peter F. Hamilton (start with The Reality Dysfunction), if you liked Stephenson.
Problem #2: Disproving "trade secret" status is pointless(not to mention, unlikely to happen). It's still copyright SOMEONE ELSE, and YOU CAN'T USE IT unless they let you!
SCO probably can't claim copyright infringement, because they themselves have published the same Linux kernel code, under the GPL (the SRPMS for their Linux distribution include pristine kernel sources for [I think] 2.4.13). However, perhaps they can claim that their trade secrets were wrongly published, dependong on what's actually happened. Protection of trade secrets applies only to unpublished secrets. If you fail to prove that case because the work has been published, then you still have copyright protection to fall back on.
So SCO have two possible levels of protection for their IP, they're probably just trying to make use of them in the most sensible order. As for wether they have a case or not, it's difficult to say because nobody is telling what the detail of the claims are. My guess is that SCO's case is pretty weak and even if it weren't, any contaminated code can be replaced by the Linux devlopment community pretty fast.
I think you don't stand a chance. To get the course material updated, you will have to do one of two things:-
Get the lecturer replaced with someone else - this means someone else has to be willling to teach the course
Find the lecturer a whole lot of free time to revise the course material (which I assume has been generated over a period of years) all at once. This probably means them taking time away from research, which is what you professor probably feels he's there for anyway.
Even if you succeed, the material won't be updated while you're on the course. At best, the next course would start with the new material.
(This reflects the situation in the UK, where academic teaching staff in Universities almost always have research commitments (and publications are used as a performance metric).
Some of the material you are working with is not so bad, either. Learning about RS232 might teach you several things that are generically useful in designing system interfaces:-
It's Not The Hardware, It's The Protocol Design, Stupid
Resilience versus Bandwidth (e.g. max reliable baud rate ~ 10000/(RS232 cable run in feet))
It's been a while since I've worked heavily in industrial interfacing, but I'd be surprised if USB is even relevant to that at all. Think more along the lines of RS422, 10baseT, and optical fibre (often carrying converted RS232, in fact).
I'm not particularly familiar with XMODEM, but I think it's likely to help you undersand valuable facets from the above (bandwidth/reliability tradeoffs, protocol features for catching errors, latency versus throughput, bandwidth-delay products). Token Ring seems an odd choice to me, though. After all the hardware must be tricky to get these days (or perhaps your course has no hands-on component, which would make hardware availability irrelevant).
One of the most interesting hardware interfacing things I've done was implement both ends of a mostly-symmetrical serial protocol. One end was implemented as a set of four cooperating threads, and the other as a state machine. One way of doing it was (in that case) much much easier than the other (less code and more reliable).
For arbitrary-precision computation, I use Bruno Haible's excellent CLN library. This is an extremely flexible and elegant library for doing various types of arbitrary precision computation (you can increase the precision as you go, which greatly improves the performance of algorithms like root polishing).
CLN is truly impressive. I remember reading that it switches from one multiplication algorithm to another once you get past 10,000 digits!
I wonder if this isn't some of the technology they snarfed from Sequent? I worked there in the late '80s and they were one of the top Unix technology shops around (or at least we thought so of ourselves at the time).
That was probably true in the 80s. It hasn't been true for a while though, I think.
I used a cluster of Sequent NUMA-Q machines running DYNIX 4.4.2 in 1999 (in fact, I still use them occasionally). I find DYNIX (at least, that version) to be the most annoying Unix implementation I've ever used. It's so antiquated!
It also had annoying features like telnetd defaulting to stripping the 8th bit of the data stream (turning the UK sterling symbol into a #). Oh, yes, and there was a hard-coded limit on the number of lines "tail" would cope with.
The support is good though (but I've only used the support since Sequent were bought by IBM).
I'm very surprised to see a good review of a QUE book. I find that the ones I've read - and that includes a QUE book of which I was one of several authors - are pretty dire.
The problem with QUE books (and other Macmillan Computer Publishing imprints) is attention to detail. Their production processes tend to introduce errors (for example, by loading the text into Word and having it change all the backticks to apostrophes - that happened to me!). Also, they don't usually seem to do reprints correcting errors, they just seem either to produce a new edition ("Special Edition", whatever) with a "Featuring FooMatic 97!" badge on the cover.
Another problem with QUE books is that they just tend to be written and published too fast - no time for doing a good job.
I should emphasise that Macmillan Computer Publishing, who produce QUE books, are as far as I know completely unrelated to the British publisher, Macmillan.
Disclaimer: You should know that I've had a bad experience as a contributing author of several MCP books, and have vowed not to have anything to do with them again. So as you can see I'm very biased against them. I have not read the "Linux Programming by Example" book and indeed haven't made any comments about this book in particular.
The one thing that bugs me about this is that why does a government organization that does not take part in any trade, own the trademark on something?
But the BBC does take part in trade. For a start, they market their TV propgrammes across the world (e.g. Teletubbies, as a famous example, but of course many more). They also sell products other than broadcast rights, too. See the BBC Shop.
Slashdot Mirror
I understand the first sentence above. I understand the second sentence. Why does the first demonstrate the second, though?
If you mean Margaret Thatcher, she is already a BaronessIn fact, the jargon term for an organisation large enough to actually need middleware is - "enterprise". They're often not referred to as companies because (i) they may not be commercial organisations and (ii) they're often large enough to include several organisations that are large companies in their own right.
So, perhaps the words "enterprise" and "middleware" seemed to the reviewer like vague corporate fluff words simply becuase they don't correspond to things in his/her world-view. However, they're real concepts and useful words.
There's a description of the EAL certification levels in the at the NIST site which is linked to from the top-level article. The point about this certification from Linux's point of view is that it allows it to be cinsidered for various sorts of Government deployment, which often require EAL certification to a certain level.
On the other hand, if their point is that IBM's actions in relation to the material they have licensed prejudices SCO's business then they would need to ask Novell to take action. It might make sense for the contract to cover this possibility, but I haven't read it and so I don't know if it's there or not.
A common interpretation of this fact is that the GPL is strong enough (remember it's not a licence that anybody is forced to adopt, it's not like an EULA) that none of the companies that have been caught to date have gone all the way to court when challenged by the FSF - they've all settled.
In any case though, the SCO case isn't really about the GPL, it's about their allegation that IBM has done things thay they had contractually agreed not to do or were otherwise prohibited from doing.
If SCO wants to be awarded damages for this, then they have a problem. In order to get a good award for damages you have to be able to show that you took action promtply to make the problem stop, as opposed to waiting longer in order to inflate your damages claim. Hence according to this doctrine SCO should indicate immediately the specific nature and identity of the problematic material in order to limit the damage they're suffering from.
On the other hand of course they may be able to counter this point on the basis that the code is already available freely and it would be in effect impossible to force destruction of all the available copies of the offending code, and so they're not doing further damage by keeping quiet about exactly what code is tainted.
I think the Cobalt systems were MIPS-based, not ARM-based.
There are other UK manufacturers who almost certainly assemble their own DVD players. These include Arcam and Roksan.
IBM IMS is over 35 years old (the first version dates from August 14, 1968, the same day Halle Berry was born). It's still supported.
I've used manual-focus Pentax cameras for about 15 years. I've been very happy, but I used to get a proportion of poorly-focussed exposures. That was laziness, but it has to be said that the split-prism focussing mechanism often works poorly with small aperture lenses. I borrowed someone's short Pentax zoom and was very impressed; the pictures were coming out much more visually pleasing than the ones I had taken with my own (third-party Pentax-fit) lenses.
This convinced me that what I really needed to do was to have the option of auto-focus for convenience but that I also needed to make more sensible choices about who I bought the lenses from (the Pentax own-bran lenses are very good indeed, far, far better than the 'generic' lenses I was using). Since I would have to replace all my existing lenses anyway, over time, my existing investment in Pentax KA-fit third-party lenses was moot. Therefore I decided to switch to either Nikon or Canon (although Pentax probably has the best availability of second-hand lenses at good prices, there is a wider selection of new lenses for Nikon and Canon cameras).
What it came down to in the end was that I tried the Nikon and Canon cameras out and chose the one whose user interface I preferred. While my choice was not without drawbacks (the camera I have ended up with won't accept manual-focus lenses) I'm happy with it. My photographs have improved, certainly.
In summary, I would say that I've found auto-focus to be very useful, and I'd also advise you to buy the lenses made by your camera's manufacturer (e.g. buy Pentax, Canon or Nikon lenses and try to avoid buying third-party 'equivalent' products).
I'll buy a digital camera eventually, but I'm waiting until the cameras with full-size sensors are affordable (they exist currently but are too expensive for me to buy).
The point is that the way you determine how much RAM there is in the box is to use a BIOS call that returns the number of accessible paragraphs in the first contiguous bit of RAM. There's no way for it to tell you about some other large lump of RAM which lives up there beyond the address of the monochrome display, for example.
Not by the way that I really rated Microcosm, it was really quite buggy and was overtaken by HTML, which of course turned out to be the category-killer in the hypertext arena.
Linux 2.0.33 was released on 16 Dec 1997.
Linux 2.0.34 was released on 03 Jun 1998.
Linux 2.1.99 was released on 20 Apr 1998.
Linux 2.1.100 was released on 07 May 1998.
It looks to me as if SMP was introduced to Linux in kernel version 1.3.26 (13 Sep 1995). The patch is here.
The one I use is a Musical Fidelity X-LPS, which I find works very well. You can plug it into your amplifier (which is how I use it for normal listening) and then connect your PC to the tape or MD output jacks of the amp to do the recording, or you could do it the other way and plug the X-LPS line-level outputs directly into the PC (I do it this way).
The critical thing when using Gramofile is to get the recording level right (this is the "igain" control in your audio mixer). If you get it wrong, you will saturate the A/D converter's input. This only needs to happen very occasionally to ruin the recording, and it normally happens at sractches. However, Gramofile, while it does a good job with scratches generally, can't deal so effectively with the aftereffects of saturating the soundcard's input (you tend to get a kind of echo of the crackle). So, even if it tells you that "0.0%" of the samples were at full-scale, check the actual number of full-scale samples.
The best way to do this in my opinion is to launch the ReZound audio editor. This will colour-code the full-scale regions of the sample file, enabling you to identify at a glance if you need to re-record.
Lastly, I suppose this is a rather obvious point, but the result of doing this will never be as good as the results you get listening to the original record. You can only lose information, not recover it. So, if you really care about those LPs, invest in a good turntable and cartridge! This doesn't have to be so expensive. I bought a second-hand LP12 earlier this year for less than 1/3 the price of a new one (obviously to do justice to it I will need to get a much better sound card than the one that comes on my PC's motherboard).
Less "hard" SF to consider - The Stars My Destination, by Alfred Bester, Nova by Samuel R. Delany. Maybe even Peter F. Hamilton (start with The Reality Dysfunction), if you liked Stephenson.
So SCO have two possible levels of protection for their IP, they're probably just trying to make use of them in the most sensible order. As for wether they have a case or not, it's difficult to say because nobody is telling what the detail of the claims are. My guess is that SCO's case is pretty weak and even if it weren't, any contaminated code can be replaced by the Linux devlopment community pretty fast.
- Get the lecturer replaced with someone else - this means someone else has to be willling to teach the course
- Find the lecturer a whole lot of free time to revise the course material (which I assume has been generated over a period of years) all at once. This probably means them taking time away from research, which is what you professor probably feels he's there for anyway.
Even if you succeed, the material won't be updated while you're on the course. At best, the next course would start with the new material.(This reflects the situation in the UK, where academic teaching staff in Universities almost always have research commitments (and publications are used as a performance metric).
Some of the material you are working with is not so bad, either. Learning about RS232 might teach you several things that are generically useful in designing system interfaces :-
It's been a while since I've worked heavily in industrial interfacing, but I'd be surprised if USB is even relevant to that at all. Think more along the lines of RS422, 10baseT, and optical fibre (often carrying converted RS232, in fact).
I'm not particularly familiar with XMODEM, but I think it's likely to help you undersand valuable facets from the above (bandwidth/reliability tradeoffs, protocol features for catching errors, latency versus throughput, bandwidth-delay products). Token Ring seems an odd choice to me, though. After all the hardware must be tricky to get these days (or perhaps your course has no hands-on component, which would make hardware availability irrelevant).
One of the most interesting hardware interfacing things I've done was implement both ends of a mostly-symmetrical serial protocol. One end was implemented as a set of four cooperating threads, and the other as a state machine. One way of doing it was (in that case) much much easier than the other (less code and more reliable).
CLN is truly impressive. I remember reading that it switches from one multiplication algorithm to another once you get past 10,000 digits!
The Debian project page for CLN is here
That was probably true in the 80s. It hasn't been true for a while though, I think.
I used a cluster of Sequent NUMA-Q machines running DYNIX 4.4.2 in 1999 (in fact, I still use them occasionally). I find DYNIX (at least, that version) to be the most annoying Unix implementation I've ever used. It's so antiquated!
It also had annoying features like telnetd defaulting to stripping the 8th bit of the data stream (turning the UK sterling symbol into a #). Oh, yes, and there was a hard-coded limit on the number of lines "tail" would cope with.
The support is good though (but I've only used the support since Sequent were bought by IBM).
I'm very surprised to see a good review of a QUE book. I find that the ones I've read - and that includes a QUE book of which I was one of several authors - are pretty dire.
The problem with QUE books (and other Macmillan Computer Publishing imprints) is attention to detail. Their production processes tend to introduce errors (for example, by loading the text into Word and having it change all the backticks to apostrophes - that happened to me!). Also, they don't usually seem to do reprints correcting errors, they just seem either to produce a new edition ("Special Edition", whatever) with a "Featuring FooMatic 97!" badge on the cover.
Another problem with QUE books is that they just tend to be written and published too fast - no time for doing a good job.
I should emphasise that Macmillan Computer Publishing, who produce QUE books, are as far as I know completely unrelated to the British publisher, Macmillan.
Disclaimer: You should know that I've had a bad experience as a contributing author of several MCP books, and have vowed not to have anything to do with them again. So as you can see I'm very biased against them. I have not read the "Linux Programming by Example" book and indeed haven't made any comments about this book in particular.