Oh, another little point that the article messes up, and that is somewhat amusing. ELF is not "similar to Microsoft DLLs", or that's badly worded. It's similar to Microsoft PE format.
ELF is derived from COFF. It was mostly a rewrite of COFF with some bad assumptions and nn-portabilities fixed. It so happens that Microsoft's PE (PE-COFF) format is also derived from COFF and is very similar to ELF. If the format was somehow "protected" (which wouldn't be via copyright as pointed out elsewhere), then Microsoft are also guilty of copying. If SCO really own the copyrights to Unix (they don't), and if copyright applied here (it doesn't), then MS are in the same boat with everybody else. Lucky for them that SCO don't have a leg to stand on:-)
Regarding RCI, no SCO don't have a patent on RCU (as I'm sure you know:-). IBM do. It was invented at Sequent, and patented by Sequent. As IBM bought Sequent in 1999, they own the patent on RCU, and can do whatever they please with it. SCO's nonsense argument about derivative works wouldn't help them even if it were correct (which it isn't). The method is not specific to Unix.
As regards JFS, the Linux code is derived from the OS/2 version. This has been repeated time after time, but it doesn't suit SCO's story, so they keep peddling the same lies as though that somehow makes them true.
Interesting. I'll have to play around with the mpeg2->mpeg2 transcoding myself. I'm quite prepared to believe you:-)
Regarding the quality on the TiVos, it wasn't an entirely fair comparison, because those morons at Comcast only shipped the castrated version of the Motorola digital cable box round here with no S-VHS out, only composite (RCA). Nonetheless, encoding on an analog TiVo at best quality still didn't compare well. The other part of that is the relative levels of compression used on the digital cable vs sattelite.
"First of all, the quality lost to converting Digital to Analog to Digital isn't that great. You have a very, very strong and clear Analog signal from your digital reciever. But just as importantly, you are just going to re-encode it to the same lossy format it was already in (namely, MPEG-2). That means your Analog to Digital lossy encoding isn't going to drop any significant ammount of data from the video... It'll have the same artifacts in the same places, it'll drop the same information, etc."
Two points here: 1) The DirecTV head uses an extremely expensive high quality MPEG encoder just like those "nice" people who master the video for DVDs. The quality for a given bit rate is most definitely higher than that produced by a $20 chip on a consumer PC card.
2) On what basis to you claim that repetetive lossy encoding and decoding loses little significant data? It's certainly true that repeatedly decoding and encoding mp3s degrades the sound quality and I fail to see why mpeg2 video is radically different. A single extra pass isn't going to make a huge difference, but I've used a standalone TiVo on digital cable and switched to a DirecTiVo and the quality is very noticable superior on the DirecTiVo.
Ummm, did you look at http://www.apple.com/mpeg4/aac/ which states:
AAC compressed audio at 128 kbps (stereo) has been judged by expert listeners to be "indistinguishable" from the original uncompressed audio source.*
Now, admittedly they attribute this to Dolby Labs, the "indistinguishable" is in quotes (interesting), and I quite agree that it is astoundingly good at that bit rate, but it is NOT indistinguishable and that claim should not be made.
I totally agree with the rest of your comment. I wasn't trying to make Apply the "bad guy" here. But the fact that others make totally outrageous and unrealistic claims does not justify Apply "stretching" the truth either. The irony is that if the audio circuitry in the iPod weren't so damned good, you probably wouldn't be able to tell the difference:-)
Oh, ripping at 192kbps AAC or using Lame with preset standard both leave me unable to distinguish in blind testing. Not to say that there are no differences even at that bit rate, but I can't consistently call out which is which.
I have a 40GB iPod. I started ripping using the default encoding (AAC at 128kbps). For background listening or on the cheap ear buds, it's fine. Through my Headroom amp and Sennheiser HD580s, or played through the hi-fi (NAIM equipment, ProAC speakers), it is not such a pleasant experience - the artifacts of encoding are not at all subtle. The point being made is that it's advertised as CD quality, and you can't obtain a higher quality encoding from the iTMS store, yet it is clearly a long way from CD quality on hi-fi equipment. So, if you intend to do serious listening, and buy in to the "it's CD quality", you're going to be disappointed. It's false advertising, or at least stretching a point to breaking point.
Currently playing with various other encodings, but I think I'm probably going with 'lame -present standard' which gives much better results without generating huge files (~192-200kbps seems to be the average result).
As regards the SACD/DVD-A vs iPods, I believe there are several reasons you fail to mention for the relative success or failure. The biggest one, is that those morons at the RIAA are so paranoid about copying that they've made both systems massively user unfriendly. Hooking up six or seven analog cables between the player and your AV amp because they won't let you have access to the digital signal is not going to make most people race out and buy one. Add to the the stupid prices for the media compared to buying a DVD with usually over double the content (in minutes) as well as sundry extras, and DVD-A/SACD start to look like *very* poor value for your entertainment dollar. I think the quality argument comes a long way down the list after these. The iTMS store has convenience in spades, and that's driving the sales.
Well, they're losing me as a customer. Portland, OR, with a multi-band GSM phone. It's unusable at home (about 4 miles from the centre of Portland), and drops out in multiple other places. Far from improving, service seems to have deteriorated over the last year. Oh, and their voice prices are not good and the data plan is ludicrous.
I'm switching to T-mobile. Reception is in a different class (already tested with a friend's phone), unlimited data plan for $19.99 a month etc. etc. AT&T/Cingular need to get a serious clue or they're going to have no customers left. They already lost a huge number late last year after their system upgrade disaster.
'tis a pity. When I first used them back in the mid 90s, they offered a decent service at a reasonable price. Sadly no longer.
I'm not sure I see your point. Of course people aren't going to continue to work on an support a driver for hardware that no longer exists except in a museum. That would be crazy. The point is that if the source to an older driver is available, and it is somehow vitally important to you that you keep your ancient hardware yet need to update Xfree (not clear why this would be anyway), you always have that option. You can hack on it yourself if you're sufficiently talented or you can pay someone if you're not.
Or you can continue to use the older driver and software. People who are using a machine in production as opposed to a toy have few compelling reasons to "upgrade" bugfixes notwithstanding, if their current platform is doing its job.
So, yes, open-source developers "abandon hardware" too, but that doesn't leave the hardware owner stranded which is not the case for hardware that only has closed source drivers.
This, I believe, is a succinct summary of the article. Heck the VAX had a "PROT_EXEC" equivalent protection bit on the hardware pages, but for some inexplicable reason, the 386 and descendents did not. Apparently someone has woken up to the fact that it actually might be a good idea. I disagree that it wasn't necessary; it simply wasn't implemented. It's not exactly the only strange (ignorant) idea in x86 (cf. the FPU architecture). Kudos to AMD if they had the idea first.
-48V DC. Ring voltage is 2x that IIRC. Companies that sell a lot to telcos tend to offer machines that can be run from the -48V DC supply as found in your everyday CO (central office or telephone exchange as us Brits say).
The HP blade servers seem to be built to run this way by default and you buy a power-supply to convert the mains AC if you aren't a telco.
I just dumped Comcast Digital Cable and their overpriced service (after they screwed around with the lineup one time too many) and went to DirecTV with a 3-LNB dish (HD-ready) and a DirecTiVo. I should have dome this ages ago.
Let me see... DirecTV service is cheaper (as is the DirecTiVo service). Dual tuners in the DirecTiVo. Picture quality is awesome (I think it's better than many of the cable channels - looks less compressed). So far, the weather has had no effect whatsoever. Dolby digital optical sound and S-video out instead of the crap composite video and standard stereo connectors on the digital cable box. Local channels are available.
So basically pretty much everything the cable companies put out in their adverts is a bare-faced lie (another thing that annoyed me enough to get off my butt and do something).
By and large they don't. If you look hard at the numbers, the huge increases in performance are in the area of floating point. The x86 FP architecture is screwy (hideous stack-based architecture) and gcc generates extremely poor code for it. Intel's compiler generates extremely clever code for it and modern versions of icc can transform some code to use SSE IIRC. I don't think there's a huge difference for general code. I profiled a large systems app compiled with gcc and icc and the differences were 3% i.e. noise.
I'm sorry but that is utterly untrue. You may be lucky and you modem may not be capped either deliberately or more likely due to incompetence. I can assure you that this is not the case everywhere. My modem was originally capped at around 450kbytes/s when Excite@Home ran the show. The caps were changed when AT&T took over lowering download speed and increasing upload from 128kbits/s to 256kbits/s and currently I see ~210kbytes/s download speeds. It is very clearly capped. The change happened after the changeover (when they finally reconnected us after the Excite-AT&T changeover fiasco), and was immediate. I'm pretty sure that the half the neighborhood didn't suddenly sign up for cable-modem service coincident with this change:-)
Don't you remember all the fun and games with the hacks to uncap your modem and the people getting thrown off the network ?
When the companies that fail to capitalize on the cost-savings Linux can offer start losing business to those that do so, they'll either log on to the clue server or they'll be history. Everybody (alright most people) here know that the "it's not supported" line is unfounded these days. Support isn't free, but it is most certainly available.
Actually, there's a great deal of difference, and sadly, for quite a while, it's been the cause of RHAS being less stable and reliable than the 7.X, 8 and 9 "vanilla" Red Hat versions.
RHAS shipped with a 2.4.9 kernel with all sorts of interesting patches applied (such as asynchronous I/O support). If you want to see what's in there, grab the source RPM (SRPM, not kernel-source), use "rpm2cpio | cpio -idmv" to unpack it into a directory and exmaine and compare the number and scope of the patches. In my testing, RHAS has had more problems (read kernel bugs) than e.g. RH7.3, and those problems have largely been in the areas where large patches that deviate from the kernel.org kernel have been applied. The reason should be obvious to anybody who has read "The Cathedral & the Bazaar". These patches have only really been tested by Red Hat, not by the community and so they lost one of the advantages of the normal Open Source model.
RHAS is improving, but in my experience, the hype has not matched the reality thus far. The "more stable and less updates" line is belied by the list of kernel updates for instance, (2.4.9-e.{3,5,8,9,10,12,16,23,24}, and a couple of 2.4.18 kernels).
In summary, I'd reiterate what the parent poster said. If you want to run Oracle and you're really attached to Red Hat as opposed to SuSE, you will have to install RHAS. Otherwise, I'd go with some other RH distribution (actually I'd go with SuSE, but that's me:-).
Sadly, in practice, all I foresee out of that is lots of lawyers stirring up trouble and making lots more money, and very little improvement for the end-user.
Let's face it, part of the reason we have so much shoddy software about is because we, the end-users, encourage the behaviour (yes, I'm a Brit), by buying from whoever is first to market, rather than waiting for someone to release a quality debugged product. So, the people who cut corners are often rewarded and those who try to do "the right thing(TM)" are punished.
I would like to add, that the reason could be summed up as "because that is what the market rewards". As you point out, it's not that it's impossible to write "reliable" (for some definition of reliable) software, but as long as the marketplace (that's us BTW) continue to reward companies who rush out software that is not ready, and reward them for this behaviour, incidentally punishing the companies that try to do a better job, the results will be the same as we have today, i.e. largely flaky, unreliable, hard-to-support software, that, if we're lucky improves somewhat by the third release.
The write-up is misleading... The 64k is the L2 cache which is 16-way set-associative, full-speed and exclusive i.e. it doesn't overlap with the contents of the L1 cache. The L1 cache is 128k unless they've changed it (none of the immediately available info mentions the size, but that's what the current C3 has).
So, actually the chip has 192K of cache, configured pretty much the same as it was in the AMD Duron (128k L1, 64k L2, exclusive). Considering the target marketplace and performance of the chip, this seems to be plenty.
A hardware random-number generator is useful for crypto. If you've ever tried porting something like OpenSSH to a platform that didn't have decent RNG support (i.e. no/dev/random or/dev/urandom like Linux has), you'll have run into the fun and games of trying to come up with a decent random source.
Hardware support for RNG is a "Good Thing(TM)", and doesn't necessarily have anything to do with the "Trusted Computing Platform" or whatever the DRM flavour of the day happens to be !:-)
Depending on the intelligence and power of the set-top box. Historically, controls such as pause, fast-forward etc. involved the set-top box having to communicate with the server. People get annoyed very quickly when they hit pause and the video stops three seconds later. Latency is a serious pain. Clever programming can alleviate a lot of the problems, but it's just another thing that makes VoD inferior to DVDs. This killed most/all the pilots I saw several years ago.
If I decide half way through a DVD that I'm too tired, or something comes up, I can power off the player and come back the following night and carry on as though nothing had happened. I don't believe VoD offers this kind of flexibility. If the content providers could truly supply a huge library of video, fix the latency issues, charge a decent (low) price, provide the needed flexibility etc. etc., then maybe VoD has potential. I'm not aware of any provider committing to this yet.
A british grandfather was arrested and held in appalling conditions in South Africa recently because the feds claimed that he was a wanted criminal. Turned out they'd picked the wrong guy. He had the same name. They left him there for three weeks, and it was only because an anonymous tip-off caused them to catch the real guy that they did anything. His name is Derek Bond. Take a look here (http://news.bbc.co.uk/2/hi/uk_news/england/283487 7.stm) for the details.
I'm afraid you place way too much faith in the FBI etc. This is *precisely* why there were checks and balances in place which Ashcroft seems bent on systematically destroying in the name of "protecting us". Here's the thing... the FBI, CIA, government etc. are composed of human beings with all the same flaws as the rest of the human race. They make mistakes, some of them are criminals etc. That's why it's so important to have the oversight, to have these things be public, etc.
And Interactive Systems who ported System V release 3 and release 4. And, with a much closer relevance to the case, Sequent, who had 30-processor machines, that were totally Intel based and weren't running SCO. The complaint is tissue of lies. A lot of the code that has been accepted from IBM is either stuff from OS/2 (the Linux IBM JFS is derived from the OS/2 version), or in the case of things like read-copy update, Sequent technology, which IBM is entitled to since they bought Sequent.
Wouldn't make a jot of difference. The current firewalls aren't rewriting the IPid field anyway, so adding an extra hop would not affect the analysis at all.
In reading the paper, it is apparent that this is not a particularly cheap thing to attempt. I can't see how it could be easily automated and deployed on a large scale, even assuming someone could be sufficiently bothered to do so.
If you want protection from this, you're going to need to do some serious work on iptables to add tracking of fragments to the connection tracking code and to rewrite the field on outbound packets to some psuedo-random value. Interestingly this is the "correct" thing to do anyway - otherwise it is theoretically possible to generate two packets with the same id, both fragmented from different internal hosts to the same destination, and screw up the fragmentation reassembly at the receiver.
A TiVo series 1 has a 54MHz PowerPC (403 I believe). The video formatting is no more restricted than MCE - it uses MPEG2 encoding. The encoding chip is made by Sony, and the decoding chip by IBM, at least in the standalone (non DirecTiVo) units.
I find it astonishing that MCE consumes 40% cpu of a multi-gigahertz chip and still stutters, yet my sub-100MHz TiVo can record one stream and playback another without breaking a sweat.
TiVo series 2 units are a built using a MIPS core (ISTR), at around 200 MHz. This makes the UI more responsive, but the series 1 has enough power to do its job. It goes to show what a remarkably good job the TiVo engineering people did.
I don't believe it's generally available yet, but there is software in the pipeline for Series 2 owners to enable use as an MP3 jukebox, picture/slideshow viewer, and to allow remote programming of your unit over the web via TiVo's site.
So, yes, a PC is obviously a general purpose machine whereas a PVR is not, and theoretically more flexible, but in reality, the PVRs currently do the job better (cheaper, quieter...), and are quuickly expanding their capabilities.
Ummm... The current Advanced Server (2.1AS) doesn't meet your criteria, at least far as "slower" or "more conservative" is concerned. Although the kernel is still nominally based on 2.4.9, it has tons of changes, many backported from 2.5, others from elsewhere. While Red Hat certainly do not shirk on testing, the amount of "new" code in the Advanced Server kernel (particularly that included at the behest of Oracle e.g. Asynchronous I/O), is hardly helpful in achieving a solid, bug-free kernel. I have personally logged several bugs against the AS kernel, a number of which are fixed in the 2.4.18 kernel that Red Hat ship with 8.0, and as an update to 7.x, but not is AS.
Executive summary, in a number of respects the 7.x/8.0 kernel is both newer and yet more conservative and hence stable than that shipped with Advanced Server.
Slashdot Mirror
Oh, another little point that the article messes up, and that is somewhat amusing.
:-)
ELF is not "similar to Microsoft DLLs", or that's badly worded. It's similar to Microsoft PE format.
ELF is derived from COFF. It was mostly a rewrite of COFF with some bad assumptions and nn-portabilities fixed. It so happens that Microsoft's PE (PE-COFF) format is also derived from COFF and is very similar to ELF. If the format was somehow "protected" (which wouldn't be via copyright as pointed out elsewhere), then Microsoft are also guilty of copying. If SCO really own the copyrights to Unix (they don't), and if copyright applied here (it doesn't), then MS are in the same boat with everybody else. Lucky for them that SCO don't have a leg to stand on
Tim
Exactly!
:-). IBM do. It was invented at Sequent, and patented by Sequent. As IBM bought Sequent in 1999, they own the patent on RCU, and can do whatever they please with it. SCO's nonsense argument about derivative works wouldn't help them even if it were correct (which it isn't). The method is not specific to Unix.
Regarding RCI, no SCO don't have a patent on RCU (as I'm sure you know
As regards JFS, the Linux code is derived from the OS/2 version. This has been repeated time after time, but it doesn't suit SCO's story, so they keep peddling the same lies as though that somehow makes them true.
Talk about clutching at straws!
Interesting. I'll have to play around with the mpeg2->mpeg2 transcoding myself. I'm quite prepared to believe you :-)
Regarding the quality on the TiVos, it wasn't an entirely fair comparison, because those morons at Comcast only shipped the castrated version of the Motorola digital cable box round here with no S-VHS out, only composite (RCA). Nonetheless, encoding on an analog TiVo at best quality still didn't compare well. The other part of that is the relative levels of compression used on the digital cable vs sattelite.
Cheers.
"First of all, the quality lost to converting Digital to Analog to Digital isn't that great. You have a very, very strong and clear Analog signal from your digital reciever. But just as importantly, you are just going to re-encode it to the same lossy format it was already in (namely, MPEG-2). That means your Analog to Digital lossy encoding isn't going to drop any significant ammount of data from the video... It'll have the same artifacts in the same places, it'll drop the same information, etc."
Two points here:
1) The DirecTV head uses an extremely expensive high quality MPEG encoder just like those "nice" people who master the video for DVDs. The quality for a given bit rate is most definitely higher than that produced by a $20 chip on a consumer PC card.
2) On what basis to you claim that repetetive lossy encoding and decoding loses little significant data? It's certainly true that repeatedly decoding and encoding mp3s degrades the sound quality and I fail to see why mpeg2 video is radically different. A single extra pass isn't going to make a huge difference, but I've used a standalone TiVo on digital cable and switched to a DirecTiVo and the quality is very noticable superior on the DirecTiVo.
Tim
Ummm, did you look at http://www.apple.com/mpeg4/aac/ which states:
:-)
AAC compressed audio at 128 kbps (stereo) has been judged by expert listeners to be "indistinguishable" from the original uncompressed audio source.*
Now, admittedly they attribute this to Dolby Labs, the "indistinguishable" is in quotes (interesting), and I quite agree that it is astoundingly good at that bit rate, but it is NOT indistinguishable and that claim should not be made.
I totally agree with the rest of your comment. I wasn't trying to make Apply the "bad guy" here. But the fact that others make totally outrageous and unrealistic claims does not justify Apply "stretching" the truth either. The irony is that if the audio circuitry in the iPod weren't so damned good, you probably wouldn't be able to tell the difference
Oh, ripping at 192kbps AAC or using Lame with preset standard both leave me unable to distinguish in blind testing. Not to say that there are no differences even at that bit rate, but I can't consistently call out which is which.
I'm afraid I have to disagree with you.
I have a 40GB iPod. I started ripping using the default encoding (AAC at 128kbps). For background listening or on the cheap ear buds, it's fine. Through my Headroom amp and Sennheiser HD580s, or played through the hi-fi (NAIM equipment, ProAC speakers), it is not such a pleasant experience - the artifacts of encoding are not at all subtle. The point being made is that it's advertised as CD quality, and you can't obtain a higher quality encoding from the iTMS store, yet it is clearly a long way from CD quality on hi-fi equipment. So, if you intend to do serious listening, and buy in to the "it's CD quality", you're going to be disappointed. It's false advertising, or at least stretching a point to breaking point.
Currently playing with various other encodings, but I think I'm probably going with 'lame -present standard' which gives much better results without generating huge files (~192-200kbps seems to be the average result).
As regards the SACD/DVD-A vs iPods, I believe there are several reasons you fail to mention for the relative success or failure. The biggest one, is that those morons at the RIAA are so paranoid about copying that they've made both systems massively user unfriendly. Hooking up six or seven analog cables between the player and your AV amp because they won't let you have access to the digital signal is not going to make most people race out and buy one. Add to the the stupid prices for the media compared to buying a DVD with usually over double the content (in minutes) as well as sundry extras, and DVD-A/SACD start to look like *very* poor value for your entertainment dollar. I think the quality argument comes a long way down the list after these. The iTMS store has convenience in spades, and that's driving the sales.
Regards,
Tim
Well, they're losing me as a customer. Portland, OR, with a multi-band GSM phone. It's unusable at home (about 4 miles from the centre of Portland), and drops out in multiple other places. Far from improving, service seems to have deteriorated over the last year. Oh, and their voice prices are not good and the data plan is ludicrous.
I'm switching to T-mobile. Reception is in a different class (already tested with a friend's phone), unlimited data plan for $19.99 a month etc. etc. AT&T/Cingular need to get a serious clue or they're going to have no customers left. They already lost a huge number late last year after their system upgrade disaster.
'tis a pity. When I first used them back in the mid 90s, they offered a decent service at a reasonable price. Sadly no longer.
I'm not sure I see your point. Of course people aren't going to continue to work on an support a driver for hardware that no longer exists except in a museum. That would be crazy. The point is that if the source to an older driver is available, and it is somehow vitally important to you that you keep your ancient hardware yet need to update Xfree (not clear why this would be anyway), you always have that option. You can hack on it yourself if you're sufficiently talented or you can pay someone if you're not.
Or you can continue to use the older driver and software. People who are using a machine in production as opposed to a toy have few compelling reasons to "upgrade" bugfixes notwithstanding, if their current platform is doing its job.
So, yes, open-source developers "abandon hardware" too, but that doesn't leave the hardware owner stranded which is not the case for hardware that only has closed source drivers.
Mod parent up.
This, I believe, is a succinct summary of the article. Heck the VAX had a "PROT_EXEC" equivalent protection bit on the hardware pages, but for some inexplicable reason, the 386 and descendents did not. Apparently someone has woken up to the fact that it actually might be a good idea. I disagree that it wasn't necessary; it simply wasn't implemented. It's not exactly the only strange (ignorant) idea in x86 (cf. the FPU architecture). Kudos to AMD if they had the idea first.
Tim
-48V DC. Ring voltage is 2x that IIRC.
Companies that sell a lot to telcos tend to offer machines that can be run from the -48V DC supply as found in your everyday CO (central office or telephone exchange as us Brits say).
The HP blade servers seem to be built to run this way by default and you buy a power-supply to convert the mains AC if you aren't a telco.
Tim
I'm in PDX too.
:-)
I just dumped Comcast Digital Cable and their overpriced service (after they screwed around with the lineup one time too many) and went to DirecTV with a 3-LNB dish (HD-ready) and a DirecTiVo. I should have dome this ages ago.
Let me see...
DirecTV service is cheaper (as is the DirecTiVo service).
Dual tuners in the DirecTiVo.
Picture quality is awesome (I think it's better than many of the cable channels - looks less compressed). So far, the weather has had no effect whatsoever.
Dolby digital optical sound and S-video out instead of the crap composite video and standard stereo connectors on the digital cable box.
Local channels are available.
So basically pretty much everything the cable companies put out in their adverts is a bare-faced lie (another thing that annoyed me enough to get off my butt and do something).
Get Sattelite - you won't regret it
By and large they don't. If you look hard at the numbers, the huge increases in performance are in the area of floating point. The x86 FP architecture is screwy (hideous stack-based architecture) and gcc generates extremely poor code for it. Intel's compiler generates extremely clever code for it and modern versions of icc can transform some code to use SSE IIRC. I don't think there's a huge difference for general code. I profiled a large systems app compiled with gcc and icc and the differences were 3% i.e. noise.
I'm sorry but that is utterly untrue. You may be lucky and you modem may not be capped either deliberately or more likely due to incompetence. I can assure you that this is not the case everywhere. My modem was originally capped at around 450kbytes/s when Excite@Home ran the show. The caps were changed when AT&T took over lowering download speed and increasing upload from 128kbits/s to 256kbits/s and currently I see ~210kbytes/s download speeds. It is very clearly capped. The change happened after the changeover (when they finally reconnected us after the Excite-AT&T changeover fiasco), and was immediate. I'm pretty sure that the half the neighborhood didn't suddenly sign up for cable-modem service coincident with this change :-)
Don't you remember all the fun and games with the hacks to uncap your modem and the people getting thrown off the network ?
Tim
When the companies that fail to capitalize on the cost-savings Linux can offer start losing business to those that do so, they'll either log on to the clue server or they'll be history. Everybody (alright most people) here know that the "it's not supported" line is unfounded these days. Support isn't free, but it is most certainly available.
Actually, there's a great deal of difference, and sadly, for quite a while, it's been the cause of RHAS being less stable and reliable than the 7.X, 8 and 9 "vanilla" Red Hat versions.
:-).
RHAS shipped with a 2.4.9 kernel with all sorts of interesting patches applied (such as asynchronous I/O support). If you want to see what's in there, grab the source RPM (SRPM, not kernel-source), use "rpm2cpio | cpio -idmv" to unpack it into a directory and exmaine and compare the number and scope of the patches. In my testing, RHAS has had more problems (read kernel bugs) than e.g. RH7.3, and those problems have largely been in the areas where large patches that deviate from the kernel.org kernel have been applied. The reason should be obvious to anybody who has read "The Cathedral & the Bazaar". These patches have only really been tested by Red Hat, not by the community and so they lost one of the advantages of the normal Open Source model.
RHAS is improving, but in my experience, the hype has not matched the reality thus far. The "more stable and less updates" line is belied by the list of kernel updates for instance, (2.4.9-e.{3,5,8,9,10,12,16,23,24}, and a couple of 2.4.18 kernels).
In summary, I'd reiterate what the parent poster said. If you want to run Oracle and you're really attached to Red Hat as opposed to SuSE, you will have to install RHAS. Otherwise, I'd go with some other RH distribution (actually I'd go with SuSE, but that's me
Sadly, in practice, all I foresee out of that is lots of lawyers stirring up trouble and making lots more money, and very little improvement for the end-user.
Let's face it, part of the reason we have so much shoddy software about is because we, the end-users, encourage the behaviour (yes, I'm a Brit), by buying from whoever is first to market, rather than waiting for someone to release a quality debugged product. So, the people who cut corners are often rewarded and those who try to do "the right thing(TM)" are punished.
You have hit the nail on the head.
I would like to add, that the reason could be summed up as "because that is what the market rewards". As you point out, it's not that it's impossible to write "reliable" (for some definition of reliable) software, but as long as the marketplace (that's us BTW) continue to reward companies who rush out software that is not ready, and reward them for this behaviour, incidentally punishing the companies that try to do a better job, the results will be the same as we have today, i.e. largely flaky, unreliable, hard-to-support software, that, if we're lucky improves somewhat by the third release.
The write-up is misleading...
The 64k is the L2 cache which is 16-way set-associative, full-speed and exclusive i.e. it doesn't overlap with the contents of the L1 cache. The L1 cache is 128k unless they've changed it (none of the immediately available info mentions the size, but that's what the current C3 has).
So, actually the chip has 192K of cache, configured pretty much the same as it was in the AMD Duron (128k L1, 64k L2, exclusive). Considering the target marketplace and performance of the chip, this seems to be plenty.
A hardware random-number generator is useful for crypto. If you've ever tried porting something like OpenSSH to a platform that didn't have decent RNG support (i.e. no /dev/random or /dev/urandom like Linux has), you'll have run into the fun and games of trying to come up with a decent random source.
:-)
Hardware support for RNG is a "Good Thing(TM)", and doesn't necessarily have anything to do with the "Trusted Computing Platform" or whatever the DRM flavour of the day happens to be !
Depending on the intelligence and power of the set-top box. Historically, controls such as pause, fast-forward etc. involved the set-top box having to communicate with the server. People get annoyed very quickly when they hit pause and the video stops three seconds later. Latency is a serious pain. Clever programming can alleviate a lot of the problems, but it's just another thing that makes VoD inferior to DVDs. This killed most/all the pilots I saw several years ago.
If I decide half way through a DVD that I'm too tired, or something comes up, I can power off the player and come back the following night and carry on as though nothing had happened. I don't believe VoD offers this kind of flexibility. If the content providers could truly supply a huge library of video, fix the latency issues, charge a decent (low) price, provide the needed flexibility etc. etc., then maybe VoD has potential. I'm not aware of any provider committing to this yet.
Tim
Really ?
7 7.stm) for the details.
A british grandfather was arrested and held in appalling conditions in South Africa recently because the feds claimed that he was a wanted criminal. Turned out they'd picked the wrong guy. He had the same name. They left him there for three weeks, and it was only because an anonymous tip-off caused them to catch the real guy that they did anything. His name is Derek Bond. Take a look here (http://news.bbc.co.uk/2/hi/uk_news/england/28348
I'm afraid you place way too much faith in the FBI etc. This is *precisely* why there were checks and balances in place which Ashcroft seems bent on systematically destroying in the name of "protecting us". Here's the thing... the FBI, CIA, government etc. are composed of human beings with all the same flaws as the rest of the human race. They make mistakes, some of them are criminals etc. That's why it's so important to have the oversight, to have these things be public, etc.
And Interactive Systems who ported System V release 3 and release 4. And, with a much closer relevance to the case, Sequent, who had 30-processor machines, that were totally Intel based and weren't running SCO. The complaint is tissue of lies. A lot of the code that has been accepted from IBM is either stuff from OS/2 (the Linux IBM JFS is derived from the OS/2 version), or in the case of things like read-copy update, Sequent technology, which IBM is entitled to since they bought Sequent.
Wouldn't make a jot of difference. The current firewalls aren't rewriting the IPid field anyway, so adding an extra hop would not affect the analysis at all.
In reading the paper, it is apparent that this is not a particularly cheap thing to attempt. I can't see how it could be easily automated and deployed on a large scale, even assuming someone could be sufficiently bothered to do so.
If you want protection from this, you're going to need to do some serious work on iptables to add tracking of fragments to the connection tracking code and to rewrite the field on outbound packets to some psuedo-random value. Interestingly this is the "correct" thing to do anyway - otherwise it is theoretically possible to generate two packets with the same id, both fragmented from different internal hosts to the same destination, and screw up the fragmentation reassembly at the receiver.
Tim
A TiVo series 1 has a 54MHz PowerPC (403 I believe). The video formatting is no more restricted than MCE - it uses MPEG2 encoding. The encoding chip is made by Sony, and the decoding chip by IBM, at least in the standalone (non DirecTiVo) units.
...), and are quuickly expanding their capabilities.
I find it astonishing that MCE consumes 40% cpu of a multi-gigahertz chip and still stutters, yet my sub-100MHz TiVo can record one stream and playback another without breaking a sweat.
TiVo series 2 units are a built using a MIPS core (ISTR), at around 200 MHz. This makes the UI more responsive, but the series 1 has enough power to do its job. It goes to show what a remarkably good job the TiVo engineering people did.
I don't believe it's generally available yet, but there is software in the pipeline for Series 2 owners to enable use as an MP3 jukebox, picture/slideshow viewer, and to allow remote programming of your unit over the web via TiVo's site.
So, yes, a PC is obviously a general purpose machine whereas a PVR is not, and theoretically more flexible, but in reality, the PVRs currently do the job better (cheaper, quieter
Tim
Ummm...
The current Advanced Server (2.1AS) doesn't meet your criteria, at least far as "slower" or "more conservative" is concerned. Although the kernel is still nominally based on 2.4.9, it has tons of changes, many backported from 2.5, others from elsewhere.
While Red Hat certainly do not shirk on testing, the amount of "new" code in the Advanced Server kernel (particularly that included at the behest of Oracle e.g. Asynchronous I/O), is hardly helpful in achieving a solid, bug-free kernel. I have personally logged several bugs against the AS kernel, a number of which are fixed in the 2.4.18 kernel that Red Hat ship with 8.0, and as an update to 7.x, but not is AS.
Executive summary, in a number of respects the 7.x/8.0 kernel is both newer and yet more conservative and hence stable than that shipped with Advanced Server.
Tim