Whether you get a London number beginning 0207 or 0208 is now more or less random. It is no longer geographically divided as 071/0171 and 081/0181 were. London no longer runs on exchange-prefix based routing, it runs on a giant database of all the numbers, mirrored at each exchange.
A friend of mine in Catford has two phone lines in her house, where the number on the BT line is 0208 and the number on the cable line is 0207.
I believe BT can assign businesses their own choice of 0207 or 0208, for prestige purposes (businesses in Hackney proudly display 0208 signage to show they're proudly "Inner London"), but I'm not sure about that.
The problem is probably more with the one routing/decoding algorithm with fixed width fields that the number of digits.
It really is a problem with the number of digits. For example, the phone service where you phone up and it tells you the number of the last person who called you, and you can press 5 or something to ring them back. That's stored your local switch, using ten digits, and if someone with 11 digits in their number dials you, it doesn't dial them back correctly, because it has lost the final digit.
Does this imply that various kludges are required in order to make IDD work within the NANP?
No, once your local switch realises you're making an international call, it forwards all the digits to an international gateway switch which will be the terminating equipment on the US phone network. The gateway will then strip off the international prefix and country code, make a connection to that country's network, and dial the remaining digits on that network. How those digits are processed and routed depends on that country's equipment.
I used to work for an telecoms equipment manufacturer, and you wouldn't believe how much BONE-HEADED CODING there was in their American products. Their products are split into "North American" and "International" code bases, and all the North American code without fail is hardwired to exactly 10 digits and a single routing/decoding algorithm. The international code has been totally rewritten, firstly to allow for the maximum of 24 digits, plus it allows for a variety of digit decoders, so the switches can be sold in any country and not just America.
To be honest, I'm really quite proud of the international products, it's just a shame that there needs to be this divide -- the American code should have been written properly in the first place. I blame the stagnation of the US phone numbering scheme as the #1 reason behind such lazy switch programming. It's good to see it being shaken up now and again.
anyone can flagrantly disregard copyrights (in computer programs, at least) by clean-room reverse engineering and re-implementing your super-new compression algorithm from scratch in their own way and style. You can't do jack shit unless you show they actually stole your code (which they didn't, they only took a description of the idea that your code implements, and made their own implementation of that idea).
However, with patents, you have absolute ownership of ideas, not your implementations per-say. This gives you incredible control and allows you to wield incredible power. This allows you to control entire markets, rather than simply keep thieves at bay.
Nobody is really lobbying for longer patents because everyone recognises how much of a minefield they are. Even IBM and Microsoft have had to pay out huge amounts to patent-wielding shysters. Only pharmacutical companies want longer patents, because unlike the computer industry where you can sell your software the day you get your patent, pharmacuticals can't profit from their drug patents until they go through 20 years of drug approval tests.
Whereas with copyrights, there are many greedy media companies leaning on their increasingly aged laurels.
bzip and rar are both high-performance archivers. They're not intended to work at any high speed. LZW is a high speed algorithm intended to compress quickly rather than compress well. LZO is also a high-speed algorithm, but it compresses slightly better than LZW, and the decompression speed of LZO is far faster than LZW.
bzip2 (note the 2) uses simply burrows-wheeler block sorting with move to front compression, with huffman as the entropy encoder. It will remain like that forever, and not introduce any more compression algorithms. In fact, bzip (version 1, before bzip2) used arithmetic coding instead of huffman, so it actually produced better compression, but IBM et al have a bunch of patents on arithmetic coding, so bzip2 will never use them until they expire. Block-sorting is a "clever trick" to LZ compression, but it doesn't "scale", i.e. you can't put a better predictive model into it and get better compression, the best you can do is put a better sort algorithm in, and we all know that sorting is pretty much at the limits already. RAR on the other hand uses a whole load of algorithms, including Dmitry Shkarin's PPMII which is a statistical compressor that outperforms pretty much anything (at the cost of being very slow). It also has a range of "multimedia" filters, i.e. special processing for images, audio and executables that make the data easier to compress when the real compression is used. RAR isn't open source. If you want something that stands up to it that is open-source, check out 7-zip. bzip2 is not going to get better any time soon.
You're forgetting that it's the LZW compression algorithm that's patented, not the GIF image format or the images per-say.
And, when you look at it, LZW is actually quite a nice algorithm to use. It offers incredibly high speed compression and decompression, but performs better than run-length encoding. In case you hadn't noticed, many computer games use decompressed-on-the-fly graphics in their games. While it's no use for video and audio compression compared to lossy algorithims, patent-free LZW would be useful to game developers as it could improve on their often abysmal realtime compression/decompression. Many game houses are still using RLE compression. Personally, I'd recommend LZO rather than LZW, but that's just me.
Uh, yeah, right. I've only been a consultant in this field for years.
Consultant, eh? What do you think of this week's Dilbert? But honestly, Windows CE, Windows, PalmOS and Unix are not RTOSes. If you'd mentioned VxWorks, pSOS, OS-9, ThreadX or QNX, I wouldn't have doubted your mad skillz. WinCE has pretensions on being an RTOS, but people wanting "an RTOS" simply don't use it. It's an OS for a general purpose but small scale consumer computing device. It's really no use if all you want is bare bones (ie. scheduler, allocator, timers, mutexes and the odd device driver). It costs too much and is too bulky for what it does. People buy it because "it's Microsoft Windows, but on a small scale!" -- they want it purely for the GUI which looks and feels like Windows, or they want it because Windows programmers can port their applications to it. They certainly don't buy it on its merits as an RTOS, because it's the worst of them all. IMHO, PalmOS is a better OS for handheld PCs and Symbian is a better OS for phones.
Never used a PIC, but there are degrees between PIC and a Pentium.
Sure. 8 bit CPUs, 16 bit CPUs and 32 bit CPUs:) When you say "microcontroller", don't you mean "generic microprocessor core with on-board extras like I/O controllers, etc". Have you seen the PowerQUICC? It's a PowerPC core (yes, really, as in the IBM/Motorola/Apple CPU that graces many an Apple Mac) with an extra onboard coprocessor for doing Q.921/Ethernet/etc framing and control. It usually comes in at about 500 MIPS. You'll find these in these super new telecom to ATM gateway switches.
If there isn't a fancy GUI, a microcontroller can *probably* do it.
Yeah, and you can make a microcontroller based web server that does HTTP and SLIP and fits in a matchbox. Would you want to? My ADSL router is running a TCP/IP stack, does ADSL line attenuation and handles a variety of different modulation standards, ATM framing, handles the PPPoE protocol, acts as a 4 port ethernet hub, USB connectivity, does ingress/egress packet filtering and rewriting, runs an internal web server so I can configure it and run diagnostics tests, and an FTP server so I can reflash it. It runs on a single chip, the CX82310, which includes an embedded ARM940T running, as I said before, VxWorks. It does so much, it's really not feasible to have a single execution thread whose route is only changed by external interrupts. It would be a ridiculously complex (and therefore bug-prone) state machine needed to track and serve out each fragment of the diagnostic test web page as each incoming ethernet packet arrived asking for it. Discrete tasks is the only sane solution in this device. Now, do you really think Conexant would write their own timers, interrupt handlers, task schedulers and TCP/IP stack? Why should they when they can buy in an existing solution?
So, as I'm sure you mentioned, you can pick different powers of PICs / microcontrollers / embedded processors to suit your needs. These all have varying processing capabilities. Some tasks will only need a very simple 8 bit CPU programmed entirely in assembler. But as the complexity of the task increases, the more useful it is to buy in an existing RTOS rather than write your own code to do the same things as the RTOS provides. After all, most CPUs I know only have 7 (or less) external interrupts. If you need more than that, you have to multiplex them by having some sort of "true interrupt source" value available to the CPU, and that makes the hardware more expensive. It's easier to use a task scheduler which guarantees certain fractions of the CPU time and/or guarantees priority over lesser tasks and interrupts. And timers are much simpler to implement in software as discrete multiples of a single timing source (either internally from the CPU as the PowerPC allows, or an external timer, or even from the same crystal that's clocking the CPU), rather than have 20 timing crystals wired to the interrupt pins because you need 20 different timers. And even if you only used a fixed amount of RAM, it's easier to use an allocator at runtime than it is to hard-code RAM addresses. It also makes changing code easier. These things are all useful. These things are all OS services in a RTOS. Using an RTOS in your device in no way implies that you can use your device as a general purpose computer or drive a GUI, any more than using an 8 bit microcontroller with an EPROM does. Hey kids, watch me reflash my ethernet controller to make it play tetris!
You're very confused as to what an embedded OS is. I'm not surprised, because you've never worked with one.
Realtime systems regularly have a degree of complexity to them. For example, your washing machine now has a single microcontroller running the drum, the water inlets, the front panel and soap tray / door latch, etc. This is simple enough to control with a cheap PIC.
However, an engine or an office climate control device or a telecoms switch has a lot more variables to work with, and it has to work with them in realtime. A PIC will not do. So you regularly find realtime systems with embedded CPUs (like the CPU32 -- the embeddable MC68000) which are cut-down versions of microprocessors previously used in desktop computers, often with onboard I/O controllers and RAM.
In order to control all your realtime subsystems, are you going to use a fast, hot running, power guzzling CPU running code that continually polls these devices? Or, are you going to use a slower CPU running event-driven code? If you're running event-driven code, how are you going to maintain realtime control over each subsystem?
The answer is to use prioritised threads. This is all an embedded OS really is. A simple task scheduler, a memory allocator, mutexes and timers. This is all there is to an embedded OS. If you're looking for luxury, you usually find an RS232 or Ethernet driver and in extreme luxury you get a mini TCP/IP stack -- open up your ADSL router and see what it's running. Mine's running VXworks. Windows CE or PalmOS are not "embedded OSes", They're mini desktop OSs for mini desktop devices. You've obviously never seen what an engine or a telecoms switch is running. They run things like WindRiver's Tornado or Greenhills' ThreadX. They don't run pretty things with graphics and input device support.
Well, yes. But it doesn't rule out them demanding licensing fees starting from the day they told everybody. They still have a valid patent (assuming that this whole story isn't a complete wind-up, which is what it sounds like to me)
is the doctrine of laches. You can't claim back dues for patent infringement if the person you're suing honestly didn't know about your patent. This supposedly puts a stop to "submarine patents".
It's about this really bad translation of the game Zero Wing on the Megadrive. The bad guy CATS stands up and says, IN SOVIET RUSSIA, US ARE BELONG TO ALL YOUR BASE.
I'm not sure why broadcasters are up in arms about PVRs skipping adverts. Anyone who records a program rather than watch it live is going to forward through the adverts anyway, when they get around to watching it. Advertisers already know this, and they're still willing to pay for advertising because most people watch TV programs live rather than record them.
Surely, what broadcasters are worried about is the whole concept of a TV recording machine that people watch instead of live TV. The fact it skips adverts in the recording is just icing. I think they're mostly worried about losing the eyeballs of the lucrative AB demographic -- high-earning types who only watch a few select TV programs anyway. But don't they think that attacking their own viewers and branding them "thieves" is a bit misguided? How is that going to get people to watch the TV more?
The CAB format is a structure for archiving files, which can use MSZIP, LZX or Quantum compression. CHM is a completely different structure for collating HTML pages and lots of metadata, which uses a slightly tweaked form of LZX compression. That's the only thing the formats have in common.
First off, MHT is just a mime message, run mpack on it.
However, for CHM extraction, you can use this portable CHM extractor. I don't think Matthew has officially released it, but it should be OK to use. Get in touch with him if you want.
True, but you do have to admit that if you can't address data on byte boundaries, you are basically incapable of writing multi-platform software. All C compilers for general-purpose computers I have seen use 8 bits for an unsigned char.
The C specification has to be intentionally vague, so embedded systems can tweak these sorts of things to their purposes. Embedded systems don't care about byte-ordering anyway, because they're never going to meet a file format from another system.
A lot of communication-based programming can involve taking a stream from some device, like a network, and simply saying casting that data into some struct, so C can access the chunks.
No no no no no!!!!!!! Do you know how many archivers I've had to rewrite because they just cast a struct over the top of a data stream?
The only fixed size in C is the BYTE (unsigned char). Everything else will change. Never use direct memory dumps of structs for on-disk or over-net structures! When reading a data stream, read _bytes_ and convert them at runtime to the structures you desire. Now your code is not only portable across platforms, but portable across compilers, too.
I have not been able to find a HOWTO for Netfilters!
There is a HOWTO for netfilter. It's at http://netfilter.samba.org/unreliable-guides/, and it's called the Linux 2.4 Packet Filtering HOWTO. Also look at the Linux 2.4 NAT HOWTO while you're there.
Play music instead (if you've got one of those sound cards that only plays one thing at a time)
Look at the server that the sound object comes from (like an IMG tag has SRC) and block it - put it in your firewall rules, make it resolve to 127.0.0.1 in resolv.conf or hosts.ini, or add it to your junkbuster rules, whatever.
a mandatory user fee... if you use a television for any purpose in your household.
Not true. If the TV can receive the broadcast signal, you need a license. Otherwise, you're fine. The TV detector men might come round, but if you don't recieve a broadcast signal AT ALL, you'll be fine. You DO NOT have to allow TV detector men in your home, you DO NOT have to give your name and address when you buy TV equipment (although shops are required to pass it on, if you do give it, to the pisspoor company responsible for license enforcement).
IIRC the commercial broadcasters also have to pay a fee out of their advertising to help support the BBC.
No, they have to pay for their regulating bodies, the ASA and the ITC. The BBC purely runs on the license fee.
Let me see if I get this straight. Vocal slashdotters want PVRs that can skip the commercials that pay for the production of the programs.
What if I told you that the UK has TV channels with NO COMMERCIALS! I'm kidding, right? No, there really is!
And guess what, there's NO LOGO, either! (OK, so they've started putting one in for a second or two at the start and end of the program) Is this broadcaster crazy? How does it get its funding?
Now, I know that THE MARKET must dictate everything, and socialism is an EVIL THING that has NEVER WORKED, but guess what, the people of the UK actually collectively pay for these TV channels! And they like that!
They also pay for 5 radio stations (pop/rock/dance, easy listening, classical, current affairs and comedy, sport and talk) and local newsrooms up and down the country.
The issue at stake is that the channel they own, because they pay for it, is doing things that they don't like, such as producing crap TV shows and bastardising their output. So they complain. And believe it or not, they can actually win this one.
The web-page you linked to says that the printers support a number of protocols and networks, including the option of IPD/SCS support to old IBM mainframes. Perhaps you just need to change the network adapters on these printers?
Slashdot Mirror
Whether you get a London number beginning 0207 or 0208 is now more or less random. It is no longer geographically divided as 071/0171 and 081/0181 were. London no longer runs on exchange-prefix based routing, it runs on a giant database of all the numbers, mirrored at each exchange.
A friend of mine in Catford has two phone lines in her house, where the number on the BT line is 0208 and the number on the cable line is 0207.
I believe BT can assign businesses their own choice of 0207 or 0208, for prestige purposes (businesses in Hackney proudly display 0208 signage to show they're proudly "Inner London"), but I'm not sure about that.
The problem is probably more with the one routing/decoding algorithm with fixed width fields that the number of digits.
It really is a problem with the number of digits. For example, the phone service where you phone up and it tells you the number of the last person who called you, and you can press 5 or something to ring them back. That's stored your local switch, using ten digits, and if someone with 11 digits in their number dials you, it doesn't dial them back correctly, because it has lost the final digit.
Does this imply that various kludges are required in order to make IDD work within the NANP?
No, once your local switch realises you're making an international call, it forwards all the digits to an international gateway switch which will be the terminating equipment on the US phone network. The gateway will then strip off the international prefix and country code, make a connection to that country's network, and dial the remaining digits on that network. How those digits are processed and routed depends on that country's equipment.
Or rather, the number of digits.
I used to work for an telecoms equipment manufacturer, and you wouldn't believe how much BONE-HEADED CODING there was in their American products. Their products are split into "North American" and "International" code bases, and all the North American code without fail is hardwired to exactly 10 digits and a single routing/decoding algorithm. The international code has been totally rewritten, firstly to allow for the maximum of 24 digits, plus it allows for a variety of digit decoders, so the switches can be sold in any country and not just America.
To be honest, I'm really quite proud of the international products, it's just a shame that there needs to be this divide -- the American code should have been written properly in the first place. I blame the stagnation of the US phone numbering scheme as the #1 reason behind such lazy switch programming. It's good to see it being shaken up now and again.
anyone can flagrantly disregard copyrights (in computer programs, at least) by clean-room reverse engineering and re-implementing your super-new compression algorithm from scratch in their own way and style. You can't do jack shit unless you show they actually stole your code (which they didn't, they only took a description of the idea that your code implements, and made their own implementation of that idea).
However, with patents, you have absolute ownership of ideas, not your implementations per-say. This gives you incredible control and allows you to wield incredible power. This allows you to control entire markets, rather than simply keep thieves at bay.
Nobody is really lobbying for longer patents because everyone recognises how much of a minefield they are. Even IBM and Microsoft have had to pay out huge amounts to patent-wielding shysters. Only pharmacutical companies want longer patents, because unlike the computer industry where you can sell your software the day you get your patent, pharmacuticals can't profit from their drug patents until they go through 20 years of drug approval tests.
Whereas with copyrights, there are many greedy media companies leaning on their increasingly aged laurels.
bzip and rar are both high-performance archivers. They're not intended to work at any high speed. LZW is a high speed algorithm intended to compress quickly rather than compress well. LZO is also a high-speed algorithm, but it compresses slightly better than LZW, and the decompression speed of LZO is far faster than LZW.
bzip2 (note the 2) uses simply burrows-wheeler block sorting with move to front compression, with huffman as the entropy encoder. It will remain like that forever, and not introduce any more compression algorithms. In fact, bzip (version 1, before bzip2) used arithmetic coding instead of huffman, so it actually produced better compression, but IBM et al have a bunch of patents on arithmetic coding, so bzip2 will never use them until they expire. Block-sorting is a "clever trick" to LZ compression, but it doesn't "scale", i.e. you can't put a better predictive model into it and get better compression, the best you can do is put a better sort algorithm in, and we all know that sorting is pretty much at the limits already. RAR on the other hand uses a whole load of algorithms, including Dmitry Shkarin's PPMII which is a statistical compressor that outperforms pretty much anything (at the cost of being very slow). It also has a range of "multimedia" filters, i.e. special processing for images, audio and executables that make the data easier to compress when the real compression is used. RAR isn't open source. If you want something that stands up to it that is open-source, check out 7-zip. bzip2 is not going to get better any time soon.
You're forgetting that it's the LZW compression algorithm that's patented, not the GIF image format or the images per-say.
And, when you look at it, LZW is actually quite a nice algorithm to use. It offers incredibly high speed compression and decompression, but performs better than run-length encoding. In case you hadn't noticed, many computer games use decompressed-on-the-fly graphics in their games. While it's no use for video and audio compression compared to lossy algorithims, patent-free LZW would be useful to game developers as it could improve on their often abysmal realtime compression/decompression. Many game houses are still using RLE compression. Personally, I'd recommend LZO rather than LZW, but that's just me.
US Patent 4,558,302 was filed on the 20th June 1983. Under the laws at that time, it expires exactly 20 years after being filed.
fp.
Uh, yeah, right. I've only been a consultant in this field for years.
:) When you say "microcontroller", don't you mean "generic microprocessor core with on-board extras like I/O controllers, etc". Have you seen the PowerQUICC? It's a PowerPC core (yes, really, as in the IBM/Motorola/Apple CPU that graces many an Apple Mac) with an extra onboard coprocessor for doing Q.921/Ethernet/etc framing and control. It usually comes in at about 500 MIPS. You'll find these in these super new telecom to ATM gateway switches.
Consultant, eh? What do you think of this week's Dilbert? But honestly, Windows CE, Windows, PalmOS and Unix are not RTOSes. If you'd mentioned VxWorks, pSOS, OS-9, ThreadX or QNX, I wouldn't have doubted your mad skillz. WinCE has pretensions on being an RTOS, but people wanting "an RTOS" simply don't use it. It's an OS for a general purpose but small scale consumer computing device. It's really no use if all you want is bare bones (ie. scheduler, allocator, timers, mutexes and the odd device driver). It costs too much and is too bulky for what it does. People buy it because "it's Microsoft Windows, but on a small scale!" -- they want it purely for the GUI which looks and feels like Windows, or they want it because Windows programmers can port their applications to it. They certainly don't buy it on its merits as an RTOS, because it's the worst of them all. IMHO, PalmOS is a better OS for handheld PCs and Symbian is a better OS for phones.
Never used a PIC, but there are degrees between PIC and a Pentium.
Sure. 8 bit CPUs, 16 bit CPUs and 32 bit CPUs
If there isn't a fancy GUI, a microcontroller can *probably* do it.
Yeah, and you can make a microcontroller based web server that does HTTP and SLIP and fits in a matchbox. Would you want to? My ADSL router is running a TCP/IP stack, does ADSL line attenuation and handles a variety of different modulation standards, ATM framing, handles the PPPoE protocol, acts as a 4 port ethernet hub, USB connectivity, does ingress/egress packet filtering and rewriting, runs an internal web server so I can configure it and run diagnostics tests, and an FTP server so I can reflash it. It runs on a single chip, the CX82310, which includes an embedded ARM940T running, as I said before, VxWorks. It does so much, it's really not feasible to have a single execution thread whose route is only changed by external interrupts. It would be a ridiculously complex (and therefore bug-prone) state machine needed to track and serve out each fragment of the diagnostic test web page as each incoming ethernet packet arrived asking for it. Discrete tasks is the only sane solution in this device. Now, do you really think Conexant would write their own timers, interrupt handlers, task schedulers and TCP/IP stack? Why should they when they can buy in an existing solution?
So, as I'm sure you mentioned, you can pick different powers of PICs / microcontrollers / embedded processors to suit your needs. These all have varying processing capabilities. Some tasks will only need a very simple 8 bit CPU programmed entirely in assembler. But as the complexity of the task increases, the more useful it is to buy in an existing RTOS rather than write your own code to do the same things as the RTOS provides. After all, most CPUs I know only have 7 (or less) external interrupts. If you need more than that, you have to multiplex them by having some sort of "true interrupt source" value available to the CPU, and that makes the hardware more expensive. It's easier to use a task scheduler which guarantees certain fractions of the CPU time and/or guarantees priority over lesser tasks and interrupts. And timers are much simpler to implement in software as discrete multiples of a single timing source (either internally from the CPU as the PowerPC allows, or an external timer, or even from the same crystal that's clocking the CPU), rather than have 20 timing crystals wired to the interrupt pins because you need 20 different timers. And even if you only used a fixed amount of RAM, it's easier to use an allocator at runtime than it is to hard-code RAM addresses. It also makes changing code easier. These things are all useful. These things are all OS services in a RTOS. Using an RTOS in your device in no way implies that you can use your device as a general purpose computer or drive a GUI, any more than using an 8 bit microcontroller with an EPROM does. Hey kids, watch me reflash my ethernet controller to make it play tetris!
Realtime systems regularly have a degree of complexity to them. For example, your washing machine now has a single microcontroller running the drum, the water inlets, the front panel and soap tray / door latch, etc. This is simple enough to control with a cheap PIC.
However, an engine or an office climate control device or a telecoms switch has a lot more variables to work with, and it has to work with them in realtime. A PIC will not do. So you regularly find realtime systems with embedded CPUs (like the CPU32 -- the embeddable MC68000) which are cut-down versions of microprocessors previously used in desktop computers, often with onboard I/O controllers and RAM.
In order to control all your realtime subsystems, are you going to use a fast, hot running, power guzzling CPU running code that continually polls these devices? Or, are you going to use a slower CPU running event-driven code? If you're running event-driven code, how are you going to maintain realtime control over each subsystem?
The answer is to use prioritised threads. This is all an embedded OS really is. A simple task scheduler, a memory allocator, mutexes and timers. This is all there is to an embedded OS. If you're looking for luxury, you usually find an RS232 or Ethernet driver and in extreme luxury you get a mini TCP/IP stack -- open up your ADSL router and see what it's running. Mine's running VXworks. Windows CE or PalmOS are not "embedded OSes", They're mini desktop OSs for mini desktop devices. You've obviously never seen what an engine or a telecoms switch is running. They run things like WindRiver's Tornado or Greenhills' ThreadX. They don't run pretty things with graphics and input device support.
wtf dude, he's only calling you a troll to wind you up. yhbt.
Well, yes. But it doesn't rule out them demanding licensing fees starting from the day they told everybody. They still have a valid patent (assuming that this whole story isn't a complete wind-up, which is what it sounds like to me)
is the doctrine of laches. You can't claim back dues for patent infringement if the person you're suing honestly didn't know about your patent. This supposedly puts a stop to "submarine patents".
It's about this really bad translation of the game Zero Wing on the Megadrive. The bad guy CATS stands up and says, IN SOVIET RUSSIA, US ARE BELONG TO ALL YOUR BASE.
I'm not sure why broadcasters are up in arms about PVRs skipping adverts. Anyone who records a program rather than watch it live is going to forward through the adverts anyway, when they get around to watching it. Advertisers already know this, and they're still willing to pay for advertising because most people watch TV programs live rather than record them.
Surely, what broadcasters are worried about is the whole concept of a TV recording machine that people watch instead of live TV. The fact it skips adverts in the recording is just icing. I think they're mostly worried about losing the eyeballs of the lucrative AB demographic -- high-earning types who only watch a few select TV programs anyway. But don't they think that attacking their own viewers and branding them "thieves" is a bit misguided? How is that going to get people to watch the TV more?
The CAB format is a structure for archiving files, which can use MSZIP, LZX or Quantum compression. CHM is a completely different structure for collating HTML pages and lots of metadata, which uses a slightly tweaked form of LZX compression. That's the only thing the formats have in common.
First off, MHT is just a mime message, run mpack on it.
However, for CHM extraction, you can use this portable CHM extractor. I don't think Matthew has officially released it, but it should be OK to use. Get in touch with him if you want.
However, using Makefiles leads to really ugly bungles. Autoconf doesn't, to my knowledge, have any kind of support for this.
../package-version/configure
autoconf doesn't, but automake (or any other GNU Makefile standards-compliant makefile generator) can.
Try this:
% tar zxf package-version.tar.gz
% mkdir build-package
% cd build-package
%
% make
% make install
All your makefiles and such will be built in the build-package directory instead of the source tree.
Hint: #include , then take a look at CHAR_BIT.
True, but you do have to admit that if you can't address data on byte boundaries, you are basically incapable of writing multi-platform software. All C compilers for general-purpose computers I have seen use 8 bits for an unsigned char.
The C specification has to be intentionally vague, so embedded systems can tweak these sorts of things to their purposes. Embedded systems don't care about byte-ordering anyway, because they're never going to meet a file format from another system.
A lot of communication-based programming can involve taking a stream from some device, like a network, and simply saying casting that data into some struct, so C can access the chunks.
No no no no no!!!!!!! Do you know how many archivers I've had to rewrite because they just cast a struct over the top of a data stream?
The only fixed size in C is the BYTE (unsigned char). Everything else will change. Never use direct memory dumps of structs for on-disk or over-net structures! When reading a data stream, read _bytes_ and convert them at runtime to the structures you desire. Now your code is not only portable across platforms, but portable across compilers, too.
I have not been able to find a HOWTO for Netfilters!
There is a HOWTO for netfilter. It's at http://netfilter.samba.org/unreliable-guides/, and it's called the Linux 2.4 Packet Filtering HOWTO. Also look at the Linux 2.4 NAT HOWTO while you're there.
Nice, you ignore my points by labelling me a troll.
You're not a troll, you're a filthy, dirty hun. Never forget that.
a mandatory user fee ... if you use a television for any purpose in your household.
Not true. If the TV can receive the broadcast signal, you need a license. Otherwise, you're fine. The TV detector men might come round, but if you don't recieve a broadcast signal AT ALL, you'll be fine. You DO NOT have to allow TV detector men in your home, you DO NOT have to give your name and address when you buy TV equipment (although shops are required to pass it on, if you do give it, to the pisspoor company responsible for license enforcement).
IIRC the commercial broadcasters also have to pay a fee out of their advertising to help support the BBC.
No, they have to pay for their regulating bodies, the ASA and the ITC. The BBC purely runs on the license fee.
Let me see if I get this straight. Vocal slashdotters want PVRs that can skip the commercials that pay for the production of the programs.
What if I told you that the UK has TV channels with NO COMMERCIALS! I'm kidding, right? No, there really is!
And guess what, there's NO LOGO, either! (OK, so they've started putting one in for a second or two at the start and end of the program) Is this broadcaster crazy? How does it get its funding?
Now, I know that THE MARKET must dictate everything, and socialism is an EVIL THING that has NEVER WORKED, but guess what, the people of the UK actually collectively pay for these TV channels! And they like that!
They also pay for 5 radio stations (pop/rock/dance, easy listening, classical, current affairs and comedy, sport and talk) and local newsrooms up and down the country.
The issue at stake is that the channel they own, because they pay for it, is doing things that they don't like, such as producing crap TV shows and bastardising their output. So they complain. And believe it or not, they can actually win this one.
The web-page you linked to says that the printers support a number of protocols and networks, including the option of IPD/SCS support to old IBM mainframes. Perhaps you just need to change the network adapters on these printers?