Also notice his screenshot still shows the USB key not being mounted 'sync'. Sigh. That so needs changed. One thing at a time I guess.:)
Actually the new thing is the 'flush' mount option that don't wear out flash drives and destroys performance like 'sync' does. Someone at SUSE wrote an experimental 'flush' patch for vfat and it seems possible to do for other file systems too. It will go upstream and some point...
This is unfortunatly not going to happen anytime soon.
Since Echostar is a DVB-compliant satellite network the different channels are encoded as MPEG2 a/v streams are put in number of multiplexes of about 30 Mbps (this gives 5-10 services per multiplex depending on quality).
Using error-reducing codes, each multiplex is coded onto an analog transponder which is about 33Mhz wide. Remember that one transponder can carry one analog tv service.
Thus, the set-top box would (in the worst case) require one tuner per endpoint in your ethernet network.
There is a host of other problems I dont want to mention here including the scrambling systems, smart cards and digital rights management.
In addition, I believe anybody on your block's shared Ethernet segment can capture *all* your traffic as well if they have the right software to put their Ethernet card in promiscuous mode and do frame captures!
That depends. Most, if not all, digital cable companies here in europe have sophisticated conditional access systems (based on PKI) and the MPEG2 Transport Stream scrambling algorithm is public so it should be a walk in the park to use scrambling - that is from a theoritical POV that is. It surely would require additional expensive equipment.
AFAIK, none of the major CA systems for MPEG2 (Such as Philips Cryptoworks, Nagravision, Irdeto Access, NDS etc.) have been seriously compromised.
The word 'Documentation' as used in software engineering, is often used to characterize a number of different documents. Here are the different kind of documents I produce in my position as a lead tech in a software company:
1. Interface/API documentation: Here I normally generate latex from the C++/Java/C sources with DOC++ and publish it as PDF's. I could generate HTML but most of my collegues agree with me that printed documentation are nicer.
2. User Manuals: It varies. troff for man pages, Latex for hardcopies, M$ Word if nontechs has to edit/localize the stuff.
3. Tech Specifications, Software Design Documents: Such documents are mostly used within the company by the tech staff, so I use Latex for formatting and M$ Visio (and sometimes some fourth-generation tools such as Erwin or Rational Rose) for diagrams. It works for me! And these can be put under source control (we use CVS).
4. Collaborative documents: Such as proposals, RFPs, Site Acceptence Test documents that non-techies (Account and Project managers most of the time) has to edit.. For these I use M$ Word/Excel and I must admit I use a considerable amount of time on the things that LaTeX does automaticially for me - that is layout and presentation.
As a rule of thumb I always submit documents as PDFs. Good luck and always remember YMMV!!
Basicly it means they *might* have a breakthrough for audio/video, but it's useless for executables etc.
This will be lossy, so the above and this might be offtopic.
You know, in fact most audio/video are compressed using lossy algorithms most of the time exploiting redundancies non-percievable to the audience, such as using YUV colorspace instead of RGB and fancy transformations into frequency space from spatial space.
In the end the binary soup is often encoded using Huffman and runlength encoding. Add to this trivial (not really) motion detection and compensating algorithms and you arrive at MPEG1/MPEG2.
Dedicated circuits handle the encoding and decoding (where encoding is much more expensive).
My point is that you cannot discard the application domain when talking about compressing A/V if you want to achieve a cost-effective encoding+decoding solution. Mere non-informed compression is here a waste of time. Use what you know!
Yup, Phoenix did it on contract for Compaq, and according to the The EmuFAQ the case was tried for copyright infringement and "The courts are unable to find any proprietary IBM microcode within the Phoenix BIOS. Phoenix is cleared of all charges, and the "clean room" reverse engineering technique becomes a legitimate bulletproof means of software developement."
Well, in fact a number of companies reverse engineered the IBM BIOS in the eighties and thus created the PC clone industry. Reverse engineering on the grounds of interoperability is actually allowed, even though some orgs do not like it.
Slashdot Mirror
Actually the new thing is the 'flush' mount option that don't wear out flash drives and destroys performance like 'sync' does. Someone at SUSE wrote an experimental 'flush' patch for vfat and it seems possible to do for other file systems too. It will go upstream and some point...
> X11 is not just for Linux, you know!
Oh, sorry, you're right. It needs to be in the Amiga section.
Since Echostar is a DVB-compliant satellite network the different channels are encoded as MPEG2 a/v streams are put in number of multiplexes of about 30 Mbps (this gives 5-10 services per multiplex depending on quality).
Using error-reducing codes, each multiplex is coded onto an analog transponder which is about 33Mhz wide. Remember that one transponder can carry one analog tv service.
Thus, the set-top box would (in the worst case) require one tuner per endpoint in your ethernet network.
There is a host of other problems I dont want to mention here including the scrambling systems, smart cards and digital rights management.
That depends. Most, if not all, digital cable companies here in europe have sophisticated conditional access systems (based on PKI) and the MPEG2 Transport Stream scrambling algorithm is public so it should be a walk in the park to use scrambling - that is from a theoritical POV that is. It surely would require additional expensive equipment.
AFAIK, none of the major CA systems for MPEG2 (Such as Philips Cryptoworks, Nagravision, Irdeto Access, NDS etc.) have been seriously compromised.
The word 'Documentation' as used in software engineering, is often used to characterize a number of different documents. Here are the different kind of documents I produce in my position as a lead tech in a software company:
1. Interface/API documentation: Here I normally generate latex from the C++/Java/C sources with DOC++ and publish it as PDF's. I could generate HTML but most of my collegues agree with me that printed documentation are nicer.
2. User Manuals: It varies. troff for man pages, Latex for hardcopies, M$ Word if nontechs has to edit/localize the stuff.
3. Tech Specifications, Software Design Documents: Such documents are mostly used within the company by the tech staff, so I use Latex for formatting and M$ Visio (and sometimes some fourth-generation tools such as Erwin or Rational Rose) for diagrams. It works for me! And these can be put under source control (we use CVS).
4. Collaborative documents: Such as proposals, RFPs, Site Acceptence Test documents that non-techies (Account and Project managers most of the time) has to edit.. For these I use M$ Word/Excel and I must admit I use a considerable amount of time on the things that LaTeX does automaticially for me - that is layout and presentation.
As a rule of thumb I always submit documents as PDFs. Good luck and always remember YMMV!!
Basicly it means they *might* have a breakthrough for audio/video, but it's useless for executables etc.
This will be lossy, so the above and this might be offtopic.
You know, in fact most audio/video are compressed using lossy algorithms most of the time exploiting redundancies non-percievable to the audience, such as using YUV colorspace instead of RGB and fancy transformations into frequency space from spatial space.
In the end the binary soup is often encoded using Huffman and runlength encoding. Add to this trivial (not really) motion detection and compensating algorithms and you arrive at MPEG1/MPEG2.
Dedicated circuits handle the encoding and decoding (where encoding is much more expensive).
My point is that you cannot discard the application domain when talking about compressing A/V if you want to achieve a cost-effective encoding+decoding solution. Mere non-informed compression is here a waste of time. Use what you know!
Yup, Phoenix did it on contract for Compaq, and according to the The EmuFAQ the case was tried for copyright infringement and "The courts are unable to find any proprietary IBM microcode within the Phoenix BIOS. Phoenix is cleared of all charges, and the "clean room" reverse engineering technique becomes a legitimate bulletproof means of software developement."
;-)
Well, sort of legitimate IMHO
Well, in fact a number of companies reverse engineered the IBM BIOS in the eighties and thus created the PC clone industry. Reverse engineering on the grounds of interoperability is actually allowed, even though some orgs do not like it.