And you probably qualify as a skilled worker (unless you're down at the very bottom of MIS). Unskilled workers that are part of the "IT" definition are people like data entry clerks, whose sole job is to read a bit of paper, and enter the information on it into the computer.
As an addendum to what you've just said; if your intended use for the goods isn't obvious from what they are (e.g. I bought a DVI-A to VGA cable; it's not working for connecting a DVI-I output to VGA input, so assuming the DVI-I output is working, it's obviously faulty), then don't pick goods off the shelf - ask the salespeople to find you something to fit your purpose. That way, you have right to return if it doesn't.
Provided your concept of public directory includes the search facilities provided by P2P clients, I'm in agreement.
So long as all these copyright owners check for infringement before they send a C&D or sue, and don't do anything illegal to discover whether you are sharing copyrighted material, they can sue any infringer they like in my opinion. If that means that they run P2P clients and use the built-in search mechanism to find infringers, I'm happy. I'm only unhappy if they do one of the two following things:
Attempt to crack into my machine to see if I've got potentially infringing content that I could share. This should be obvious; if I'm not making it publically available, I'm not infringing.
Claim that a file is infringing before checking it. I should be able to put OpenOffice exes up for download as "Office.exe" without getting accused of piracy; I should be able to put up a file called "StarTrek.mpg" (a film of stars moving across the night sky) without getting accused of anything other than trademark infringement.
You missed one option that seems to be working for the RIAA; offer paid-for, legal downloads (Apple iTunes). Granted, there's a risk that your product will show up on illegal networks, too, but it gives you an argument when you're after more laws ("look, we're offering them to chance to do things legally, and they're still breaking the law!").
Alternatively, assuming that the problem is money and not control (which I'm not convinced is the case), they could offer you the chance to buy licences for content you've downloaded; this backs up the lawsuits by putting a monetary value on the losses, and providing you with a chance to avoid them in the first place.
Cost. The most expensive part of PCB manufacture is fitting each component in turn; reducing the component count (by not including a ROM) takes off the price of the ROM, the cost of routing tracks to make the ROM work, and the price of fitting the ROM.
The usual way to get the effect you want (which increases costs by the price of adding an extra chunk of flash) is to have enough flash for 2 copies of firmware plus a boot loader. Depending on the amount of flash you need, this raises costs by anything from a few cents to tens of dollars.
The boot loader fits into one or two sectors of flash, and hunts through the flash to find a valid firmware. This can be filesystem-based, or simpler (firmware can start at address x or address y. Image as supplied has first byte all ones. When a new firmware is burnt, this byte is zeroed in the old firmware, and set to 10101010 in the new firmware image. Thus, old firmware has a 0 byte, new firmware (incomplete download) has a 0xff byte, and complete active firmware has an 0xaa byte. More sophisticated boot loaders can then try switching firmware to guarantee a boot).
On every interface I've worked on, the solution is simple. Store the partly-rendered HTML as a sequence of drawing commands, pointed to by a BSP (for fast redraws of revelant portions). When it comes to time to handle the HTML where you've drawn 999 rows with 30 TD sections, then the 1000th row needs 10,000 columns, go back, amend the BSP to allow for a 10,000 column table, erase the old bit, and redraw. This is manageable in O(log n), where n is the size of the section that has changed.
Which is completely irrelevant to the problem of Turing-completeness; you're trying to use practical arguments to say that theory is wrong, and theoretical arguments to say that practice is wrong.
Either Turing-completeness is relevant, in which case expanding the argument beyond the scope of Turing-completeness is a waste of time, or it isn't, in which case you should not have brought it up.
As an alternative way to get them to admit to speaking English; don't ask them to speak English, but do your best to speak French and to understand what they're saying. Unless you're fluent in French, your accent will give you away as English-speaking, and almost everyone will try and help you improve your French. A nice bonus is that you can get to the point where you don't need them to speak English to communicate with you.
You've misunderstood again; a Perl interpreter can't know that it needs more than 64MB to run a program, or that a program will take more than an hour to run without trying it, and cutting it off when it hits a limit. In contrast, a HTML renderer can examine the HTML it's presented with, and determine relatively rapidly (and in less than 64MB) that it will take more than 64MB, or more than an hour, without attempting to render the page.
Because HTML is not Turing complete, it is possible (and in fact manageable) to take a random chunk of HTML, and determine whether you will hit any arbitrary limit; doing so will not get anywhere near that limit. Because Perl is Turing complete, the only way to determine if Perl code will hit a given limit is to run it, and abort if the limit is reached.
You're not arguing my point here; because HTML is not Turing-complete, and because it is appropriately defined, a renderer can determine in finite time (probably quite short) that a particular HTML file renders outside of its limits; it can then handle this sanely.
To take your table example; you know that your windowing system limits windows to a maximum width (32-bit unsigned int, for example). Any table with more than that number of columns is automatically replaced by an appropriate marker.
Unlike with Turing-complete languages, there is no need to guess whether something is possible or not; whether it is renderable can be determined in O(size of HTML file) time. This contrasts with (say) executing Perl; there is no way to determine whether a given Perl program will terminate.
However, with HTML, you can just render the slice that's visible to the user, rather than the entire document. Thus, assuming displays are of finite size, you can bound the complexity of the render engine.
The halting problem is only provably unsolveable for Turing-complete languages; if HTML isn't Turing-complete, it's entirely possible that you can prove that a given HTML input will or will not halt.
JavaScript is Turing-complete, so if your HTML includes JavaScript, you're doomed, but I believe that HTML and CSS are not Turing-complete, so it should be possible to prove that a given HTML input can be rendered.
Re:Is it an open protocol?
on
Replacing TCP?
·
· Score: 1
They'd have to be very careful about how they put the stack into the kernel to avoid falling foul of section 2 of the GPL; if a court were to rule that the work they'd done to put the stack into the kernel made the stack/kernel combination a collective work (or a derived work), they would have no permission to distribute the combination, unless they removed the stack and any code that derived from the stack.
If you're going to compile infrequently, and do find yourself ending up with hundreds of errors: DON'T PANIC.
The errors and warnings are almost always printed out in the order the compiler found them; fix the first one. Once you've fixed the very first error or warning, you may have completely solved the problem; continue to go down the list of errors in order until you find one that might not be an error or warning. Then recompile, and restart.
I've written C that when fed to a compiler generates a few thousand errors; once I'd fixed the first error ("Cannot find ; skipping"), they all disappeared.
Australia has DVB-T, with MP@HL video (high definition), and AC-3 audio (Dolby Digital). Europe, which is the other big DVB-T market, uses MP@ML (standard definition), and MPEG-2 audio.
If Australian DVB-T boxes support MPEG-2 audio as well as AC-3 audio, then they'll work unchanged in Europe; European boxes require simpler video streams than Australia offers, but if they have an AC-3 decoder, they'll handle the audio out there.
Because each transmission medium has different signal requirements; once you demodulate a DVB signal, the original transmission type is irrelevant, as it's all DVB.
Satellite receivers have a limited noise budget, and the need to control an LNB; they need a mechanism that's robust in the face of low SNR, and LNB control allowed.
Cable receivers live on a known stretch of wire; they need to be cheap, but capable of exploiting much higher SNRs than satellite ever has. Cable boxes don't need to worry about LNBs, varying SNRs, polarity, or anything other than a known SNR and known frequency.
Terrestrial receivers need to cope with ghosts, varying SNRs, CCI and ACI, and a whole variety of problems that satellite and cable avoid. They therefore use the most complex demodulators, which cost more than satellite or cable demodulators.
You do realise that DV is also lossy? Admittedly, DV will be at least 25MBit/s, to DVD's peak of just under 9MBit/s, but DV compression is very similar to I-frame only MPEG-2.
I get my phone out of my pocket, push a button, and the screen goes off (no backlight, no display) and the phone goes silent without vibrate turned on. If someone sees that and thinks, "Gee, I could leave my phone on", they'll do the same if I take my phone out of my pocket and switch it off fully (which is 3 button presses to get to the same apparent state).
As it is, my phone (a SonyEricsson P900 with plenty of add-on software) is set to a non-disruptive state in a minimum of time; if switching it off was faster than disabling the disruptive features, I'd switch it off, and just wait the 10 minutes it takes to restart all my usual extras.
Do you not have voicemail services in your part of the world? If you're going out of contact for a few hours, let the system take messages, and respond when you leave the cinema. If all your calls are so urgent that a caller can't leave a message and wait until the end of the movie, then rent a DVD, and stay at home.
I have never worked in a situation where I genuinely have to be on call 24/7. I've been in several where people like to assume that you are, but they back down if you guaranteed to answer between (say) 8am-7pm, and possibly available at other times.
So how is this different from a world before cellphones? Before I had a mobile, if I went to the cinema, you had to wait until I got home to contact me. Are you really claiming that emergency services have lost so many skills in the last 10 years that a two hour delay in contacting the next of kin is lethal?
In any case, the vast majority of calls aren't urgent. If most calls to cellphones were the "your relative is dying, come now" type, I'd maybe be on your side; reality is different.
I often look like I'm taking my phone out to check for messages when in the cinema; this is because I sometimes leave my phone on silent without vibrate anyway. Once I've confirmed that the phone won't ring or vibrate, I can just put it back, leaving it registered to the network, and thus making it quicker to return to normal when I leave the theatre.
This also has the added advantage that once I leave the theatre (and pull the phone out to set it back to vibrate), I can see if I've got any messages and respond quickly.
Uncompressed SD is 270MBit/s. Uncompressed 1080i HD is around 1.5GBit/s.
MPEG-2 compressed SD is barely watchable at around 2MBit/s, OK at 4MBit/s and good at 8MBit/s (DVD).
MPEG-2 compressed HD is barely watchable at 8MBit/s, OK at around 12-13MBit/s and good at around 18MBit/s (coincidentally the bitrate ATSC requires OTA broadcasters to use in the USA).
So, yes HD takes up more bits, but it's not nearly as bad as you make out.
Trouble is that the statistics are too limited; we know how many machines are bought with each OS, but there's no way to accurately estimate how many machines have their original OS removed (whether Linux or Windows).
Therefore, there's no way to tell whether the number of Linux pre-installs that are replaced with pirate Windows are balanced with the number of Windows pre-installs replaced with Linux. Gartner's prediction is that more people replace Linux with Windows than vice-versa, but how do you get to that information without guessing?
Speaking as someone who's read the specs, you're outright wrong about what Australia uses.
Both ATSC and DVB are combined service information and transmission standards, using MPEG-2 to encode video and both MPEG-2 and Dolby AC-3 for audio. Australia uses DVB with MP@HL MPEG-2 video (HD), the US uses ATSC with MP@HL MPEG-2 video, and Europe uses DVB with MP@ML (SD) MPEG-2 video.
Slashdot Mirror
It should be FC-PGA, not FPGA; FC-PGA is short for "Flip-Chip Pin Grid Array".
And you probably qualify as a skilled worker (unless you're down at the very bottom of MIS). Unskilled workers that are part of the "IT" definition are people like data entry clerks, whose sole job is to read a bit of paper, and enter the information on it into the computer.
As an addendum to what you've just said; if your intended use for the goods isn't obvious from what they are (e.g. I bought a DVI-A to VGA cable; it's not working for connecting a DVI-I output to VGA input, so assuming the DVI-I output is working, it's obviously faulty), then don't pick goods off the shelf - ask the salespeople to find you something to fit your purpose. That way, you have right to return if it doesn't.
So long as all these copyright owners check for infringement before they send a C&D or sue, and don't do anything illegal to discover whether you are sharing copyrighted material, they can sue any infringer they like in my opinion. If that means that they run P2P clients and use the built-in search mechanism to find infringers, I'm happy. I'm only unhappy if they do one of the two following things:
Alternatively, assuming that the problem is money and not control (which I'm not convinced is the case), they could offer you the chance to buy licences for content you've downloaded; this backs up the lawsuits by putting a monetary value on the losses, and providing you with a chance to avoid them in the first place.
The usual way to get the effect you want (which increases costs by the price of adding an extra chunk of flash) is to have enough flash for 2 copies of firmware plus a boot loader. Depending on the amount of flash you need, this raises costs by anything from a few cents to tens of dollars.
The boot loader fits into one or two sectors of flash, and hunts through the flash to find a valid firmware. This can be filesystem-based, or simpler (firmware can start at address x or address y. Image as supplied has first byte all ones. When a new firmware is burnt, this byte is zeroed in the old firmware, and set to 10101010 in the new firmware image. Thus, old firmware has a 0 byte, new firmware (incomplete download) has a 0xff byte, and complete active firmware has an 0xaa byte. More sophisticated boot loaders can then try switching firmware to guarantee a boot).
On every interface I've worked on, the solution is simple. Store the partly-rendered HTML as a sequence of drawing commands, pointed to by a BSP (for fast redraws of revelant portions). When it comes to time to handle the HTML where you've drawn 999 rows with 30 TD sections, then the 1000th row needs 10,000 columns, go back, amend the BSP to allow for a 10,000 column table, erase the old bit, and redraw. This is manageable in O(log n), where n is the size of the section that has changed.
Either Turing-completeness is relevant, in which case expanding the argument beyond the scope of Turing-completeness is a waste of time, or it isn't, in which case you should not have brought it up.
As an alternative way to get them to admit to speaking English; don't ask them to speak English, but do your best to speak French and to understand what they're saying. Unless you're fluent in French, your accent will give you away as English-speaking, and almost everyone will try and help you improve your French. A nice bonus is that you can get to the point where you don't need them to speak English to communicate with you.
Because HTML is not Turing complete, it is possible (and in fact manageable) to take a random chunk of HTML, and determine whether you will hit any arbitrary limit; doing so will not get anywhere near that limit. Because Perl is Turing complete, the only way to determine if Perl code will hit a given limit is to run it, and abort if the limit is reached.
To take your table example; you know that your windowing system limits windows to a maximum width (32-bit unsigned int, for example). Any table with more than that number of columns is automatically replaced by an appropriate marker.
Unlike with Turing-complete languages, there is no need to guess whether something is possible or not; whether it is renderable can be determined in O(size of HTML file) time. This contrasts with (say) executing Perl; there is no way to determine whether a given Perl program will terminate.
However, with HTML, you can just render the slice that's visible to the user, rather than the entire document. Thus, assuming displays are of finite size, you can bound the complexity of the render engine.
JavaScript is Turing-complete, so if your HTML includes JavaScript, you're doomed, but I believe that HTML and CSS are not Turing-complete, so it should be possible to prove that a given HTML input can be rendered.
They'd have to be very careful about how they put the stack into the kernel to avoid falling foul of section 2 of the GPL; if a court were to rule that the work they'd done to put the stack into the kernel made the stack/kernel combination a collective work (or a derived work), they would have no permission to distribute the combination, unless they removed the stack and any code that derived from the stack.
The errors and warnings are almost always printed out in the order the compiler found them; fix the first one. Once you've fixed the very first error or warning, you may have completely solved the problem; continue to go down the list of errors in order until you find one that might not be an error or warning. Then recompile, and restart.
I've written C that when fed to a compiler generates a few thousand errors; once I'd fixed the first error ("Cannot find ; skipping"), they all disappeared.
If Australian DVB-T boxes support MPEG-2 audio as well as AC-3 audio, then they'll work unchanged in Europe; European boxes require simpler video streams than Australia offers, but if they have an AC-3 decoder, they'll handle the audio out there.
Satellite receivers have a limited noise budget, and the need to control an LNB; they need a mechanism that's robust in the face of low SNR, and LNB control allowed.
Cable receivers live on a known stretch of wire; they need to be cheap, but capable of exploiting much higher SNRs than satellite ever has. Cable boxes don't need to worry about LNBs, varying SNRs, polarity, or anything other than a known SNR and known frequency.
Terrestrial receivers need to cope with ghosts, varying SNRs, CCI and ACI, and a whole variety of problems that satellite and cable avoid. They therefore use the most complex demodulators, which cost more than satellite or cable demodulators.
You do realise that DV is also lossy? Admittedly, DV will be at least 25MBit/s, to DVD's peak of just under 9MBit/s, but DV compression is very similar to I-frame only MPEG-2.
As it is, my phone (a SonyEricsson P900 with plenty of add-on software) is set to a non-disruptive state in a minimum of time; if switching it off was faster than disabling the disruptive features, I'd switch it off, and just wait the 10 minutes it takes to restart all my usual extras.
I have never worked in a situation where I genuinely have to be on call 24/7. I've been in several where people like to assume that you are, but they back down if you guaranteed to answer between (say) 8am-7pm, and possibly available at other times.
In any case, the vast majority of calls aren't urgent. If most calls to cellphones were the "your relative is dying, come now" type, I'd maybe be on your side; reality is different.
This also has the added advantage that once I leave the theatre (and pull the phone out to set it back to vibrate), I can see if I've got any messages and respond quickly.
Uncompressed SD is 270MBit/s. Uncompressed 1080i HD is around 1.5GBit/s.
MPEG-2 compressed SD is barely watchable at around 2MBit/s, OK at 4MBit/s and good at 8MBit/s (DVD).
MPEG-2 compressed HD is barely watchable at 8MBit/s, OK at around 12-13MBit/s and good at around 18MBit/s (coincidentally the bitrate ATSC requires OTA broadcasters to use in the USA).
So, yes HD takes up more bits, but it's not nearly as bad as you make out.
Therefore, there's no way to tell whether the number of Linux pre-installs that are replaced with pirate Windows are balanced with the number of Windows pre-installs replaced with Linux. Gartner's prediction is that more people replace Linux with Windows than vice-versa, but how do you get to that information without guessing?
Both ATSC and DVB are combined service information and transmission standards, using MPEG-2 to encode video and both MPEG-2 and Dolby AC-3 for audio. Australia uses DVB with MP@HL MPEG-2 video (HD), the US uses ATSC with MP@HL MPEG-2 video, and Europe uses DVB with MP@ML (SD) MPEG-2 video.