I had worked in the U.S. from 1997 to 1999 on a succession of NAFTA TN1 visas (two), after which my employer petitioned and received an H1B for me. I later received an LC in preparation for a Green Card, but, having to change employers, that fell through -- the H1B was successfully transferred though (this used to be a real hassle, but is less so).
The telecom bust had me return to Canada in 2003 -- the H1B was long in the tooth anyway (it's good for three years max., renewuable once, for a total of six, with special excemptions on a year over year basis if you're in the last stage of Green Card processing).
This site is one of the best I found on the subject.
Issues you will face:
1. establishing a U.S. credit history -- it was easier for me to buy a house than get a credit card for the first 12 months (mortgage lenders will be willing to do international credit checks);
2. severing Canadian tax residency -- you WILL want to do this as you will likely not be able to afford to pay Canadian-rate income taxes with U.S. expenses as well;
3. Ignoramii (ignoramuses?) -- everyone will be giving you tax and INS-related advice. Unless it comes from a tax expert or immigration lawyer, IGNORE IT -- there is lot's of missinformation around. Educate yourself -- sometimes the lawyers don't even remember everything.
4. SSN -- this is a slam dunk if you have a job, as you will need one to pay social security taxes. You will need an address... staying in a hotel for a while might be a problem. This will be more of a problem for your dependents -- for tax purposes they can get an ITIN, but some states require an SSN to issue a drivers license. There is a provision that you can get an SSN if a local government requires it -- my wife got one because she needed it to get a drivers' license in Illinois.
5. INS relationships -- let your lawyer handle things, but keep up to date on what they are doing. At the border, make sure you have your paperwork in order, have an extra copy for the INS officer to file if he or she wants, and remember, on a NAFTA TN1 visa, you are a Resident of Canada for U.S. immigration purposes and a U.S. non-resident. This, despite the fact that you will likely be a U.S. resident for tax purposes. Do not, under any circumstances, confuse the two when the INS officer asks, and do not explain the difference -- they care about immigration issues only.
Call the port of entry at the airport to find out what the best time to be processed is -- do not show up five minutes prior to your flight.
Do not lie to a U.S. immigration officer, but don't volunteer anything beyond what you're asked either.
I once sold a house in Texas to a couple from California, while living in Ontario. It doesn't strike me as that odd.
Though, in my case, the buyers' preferred lender refused the buyers' lawyer acting via a POA and they eventually had to do a cash closing.
I had the wonderful experience of using the U.S. consulate in Toronto for one of the oldest raison d'etre (reasons for being, literally) of U.S. consulates: verifying the authenticity of signatures on U.S. legal documents.
Is open source software never used for anything bad?
IIRC, the Open Source Definition does not permit a license to discriminate against a "field of endevour".
So, of course, Open Source (and Free, for that matter) software can be used for "bad" things.
But, many things can be used for "bad" things. The user, and not the creator, are responsible here (unless, of course, the creation was aimed specifically for a particular use, but then you run afoul of discriminating against other uses).
Since "good" vs. "bad" is in the eyes and mind of the beholder, or, all too often, enforced by some authority, it is probably a good thing that OSS does not permit discrimination on the basis of a field of endevour.
I think Bruce Perens uses the example of abortion clinics and anti-abortionists: both are welcome to use Open Source software.
Such clauses are generally unenforcable in the extreme. For a contract to be enforcable (i.e. for Comcast to take your money in the first place), there has to be "valuable consideration".
Contracting to exchange money for no service after advertising a service is fraud. At least the customer can't be held to pay. But, the customer does have a reasonable expextation to get something for the money they have agreed to spend.
Also, "no guarantee" is not the same as "service disconnection". In contract law, (and no, IANAL), there is the concept of "performance", that is, both parties must take reasonable efforts to perform as per their agreements. In this case, Comcast is expected to proivide internet access "much better and faster" than dial up (my quotes), that appears "unlimited", i.e. unmetered.
Their lack of a guaranteed level of service generally protects them against service interruptions, rather like when the coax to your home from the cable company breaks. Even then, they have to refund your money for service not provided. But, again, disconnection for abuse is not a service interruption.
It is reasonable for Comcast to set use limits. It is reasonable for them to throttle customers who consistently exceed them. It is not reasonable for them to advertise no limits and take harsh measures (disconnection with no means to reconnect) when some unspecified limits are exceeded.
A judge would likely look at what "unlimited" means in the market place of DSL or Cable modem internet service. It generally means, "as much as will satisfy 90, 95, or 99% of the customer base, given that the resource is not, in fact, unlimited". In other words, practically unlimited.
Every ISP I have ever dealt with that offered unlimited service made it clear that they meant "practically unlimited", and when limits were not clearly established, had a published, and rather gentle policy for dealing with causing excessive traffic that affected other customers, usually, something along the lines of "you used up this much bandwidth, that's too much, you should use less than this much over a month, here's how you can monitor it. If it happens again, we'll have to drop you, or you'll have to pay for a specified service level." They also generally have means to help the customer ensure that they do not exceed these limits: throttling them harshly when they've exceeded their monthly quota.
It's one thing to throttle or otherwise shape service, to all customers, as per the "fine print".
It's quite another to claim service is unlimited and then sever it because some unspecified limit was reached. Severing service is not the same as throttling it, and thottling it unreasonably (say, to 1 b/s) is effectively severing it, if you think you can be a smartass with semantics.
A reasonable response, when there is no guarantee of service, would be forced throttling to average customer base limits within short order of detecting "excessive" traffic for a prolonged period, lightening up on burstiness over time.
No customer can be reasonably expected to keep their use "in check" when they do not know what the limits are. This is not a criminal issue where the police are not required to advertise how fast beyond the speed limit you can drive before they stop looking the other way. This is a contractual dispute, and when there is doubt as to the meaning, they tend to settle against the drawer of the contract.
Of course, if Comcast was smart and clearly disclaimed what they meant by "unlimited", I'd side with you. But, I get the impression that their marketting department got ahead of their technical and legal departments on this one.
If that's the case, and their customer contracts permit them to unilaterally change TOS (permitting cancellation without penalty), then that's what they should do: redefine TOS to eliminate vague references to unlimited service. Even if they were in the right, legally, acting heavyhanded toward your customers is not a good way to keep them.
While IANAL, in most jurisdictions, the party who draws a contract is held to the worst possible interpretation of it, so if "unlimited" is unclear as to "time online" or "bandwidth usage", the interpretation that best serves the interest of the counterparty is taken.
The reason for this is that, as the party drawing the contract, they can word it in the best possible way for themselves. That they did not, when they had the chance, is, as we used to say as kids, "tough nookies".
This is why you have your lawyer draw contracts that you propose.
Doesn't Windows support thread-local storage, so you only share the global data you have to? Of course, a wild pointer in that area will still mess things up (rather like an irate bull in a china shop -- the bull has to be irate, though).
But, I was thinking of a separate address space for each object allocated within an object-oriented paradigm. No more falling off the end of arrays, or mis-casting pointers. I'd expect performance to suck, of course, as virtual memory tables get changed on each pointer dereference, but, one can dream.
No, I was thinking of small object allocators. Think dynamic memory allocation where you want to allocate, say, two bytes or even one dynamically, and you need a bunch of them.
Well, a traditional allocator generally maintains a doubly linked list (or other structure) of allocated or available blocks. This overhead swamps out the size of the small object you need and is grossly inefficient.
What you do, is not allocate one or two bytes at a time, but a medium-sized block of several hundred (or dozens if the block size is 10 bytes or so) in one fell swoop, and then allocate out of that smaller blocks of a given size (programs usually only deal with blocks of a small number of different known sizes).
Now, keeping track of the free small blocks within the larger blocks will involve making a linked list, yes? (well, you could use a bitmap, but that has 12.5% overhead if allocating 8 bit bytes). But, in each larger block, you only have a small number of smaller blocks, and counting (or indexing) them does not require big, wide 32 or 64 bit pointers. An example might help.
Consider an allocation where you need to dynamically allocate single eight bit bytes. You allocate a block of 255 of them, and use the numbers 1 to 255 to index them. Gee, that kind of number fits in a single byte, so you link the free list within the block that way. The only complication arises when returning a byte to the free list: which larger 255 byte block did it come from? Well, you can maintain a table of block starting addresses, and search within it to find the larger block from whence it was allocated. It helps a bit if you allocate the 255 byte blocks on 256 byte boundaries (waste a byte to contain the index to the head of the free list).
Now, searching the table of larger blocks allocated is an O(log n) operation, and returning a byte to it's correct block is an O(1) operation. Allocation is O(1): you keep a list of larger blocks of the same size.
Andrei Alexandrescu has an excellent chapter on small object allocators in his book, "Modern C++ Design".
starm wrote: "but theoritically couln't you just double all the necessary buses and registers so that the CPU doesn't get any performance degradation. Everything works the same way but with doubble the word width."
Exactly!
Except, we haven't done that yet. That's the "speed bump" to which I alluded.
Now, others have pointed out that storing more smaller bits in cache uses, well, less cache, but I'd counter that more pointer in cache increases the chance that you'll reference something out of cache and the likelihood of going out to slow DRAM. So, there's a case where smaller pointers are going to bite you, not because they're smaller though, but because you're managing so many pointers (and keeping them small for storage reasons), that your all is probably vectoring (code- or data-wise) all over the place.
Look, there will always be some application where you have to tailer the algorithm and data structures to the details of the hardware. Been there, done that. But, in general 64 bit pointers on a post-modern processor (with bigger caches, memory, etc.) will be "as fast as" 32 bit pointers on a modern machine, or 16 bit pointers on a legacy machine, or 16 bit pointers on an 8080 (which had an 8 bit data bus). Faster, actually, because of all the other speedups.
But, the very first bleeding edge move from 32 to 64 bits will likely come with a performance penalty.
Me, I like to code Foo*, i.e. pointer to Foo, and let the compiler do the right thing. Having a switch to globally control the compiler is probably a good idea. But, having my share of "near" and "far" pointers in the old segmented architecture days of the 8086/8088/80286 was painful. Of course the hit between a near and far pointer was far worse then because of the segmentaton issue. Then again, who knows how many virtual address lookup tables you'll have with a 64 bit address space.
This is true, and points out why early optimization is a bad idea. Of course, taking this view, optimization is always too early, and therefore should never be done -- wait for the faster technology. But, that isn't practical.
Really, if you had the time, you'd make your optimizations conditional, and wait for the rest of the system to do a better job than you do.
Well yes, but there is an advantage to smaller pointers when you can get away with them *if the processor has native support for them*. While exploited in small object allocators, it isn't always the case that the CPU can gallop through instructions as fast as they can be fed to it, multiple functional units notwithstanding. Though, clearly this is an issue only with data and pointers at the closest cache level to the processing units.
So, memory bandwidth remains an issue, and I concede the point.
Still, buse widths tend to optimize around typical transfer patterns, and pointers tend to grow to to be "always big enough" -- the cases where we tailor pointers to be within smaller constraints are quite specilized. It's more convenient to have one pointer size -- does anyone remember the four memory models that Microsoft C compiler used to support (probably still does)? tiny (16 bit data and code pointers), small (16 bit data, 32 bit code, IIRC), large, and huge? 'Course that isn't a perfect comparison because of the brain dead segmented x86 memory architecture, but you get the idea. It was (is) a pain.
But, bus widths and memory capacities will grow to the point where the 64 bit code of tomorrow will be as fast as the 32 bit code of today, and the need to optimize further will occur only in esoteric bits of code.
Besides, with 64 bits, you can do fun things, like allocate different objects in different virtual memory spaces and use the memory management system to catch wild-pointer bugs (because no two different objects need be adjacent in the logical memory space).
On the whole the advantages outweigh the disadvantages, and the performance penalties will be moot quite shortly.
*cough* wider data busses *cough*.
'course this does mean that 64 bit code on systems with 32 bit wide data paths will be slower, but, like, migration always involves speed bumps.
I remember the a.out to elf transition pain days of Linux.
Put the frickin Original CD in the DVD player and shut the hell up!
The whole point of a networked media client is to avoid having to have all one's media close to it. CDs get heavy and the space they take up adds up.
Or Make a Music CD from the wav or shn file and THEN put the CD in the DVD player and shut the hell up!
So, when I want to listen to something, I have to first burn a CD, and then take it to the media client? I'm too much of a couch potato for that: if I'm in the mood for Pink Floyd, I want to select Pink Floyd from the menu on the TV or webpad and go from there.
If the original "lossless" files then you can skip the mp3 format all together and leave those of us without terabytes of storage space to enjoy out music libraries in peace.
Terabytes? a 160 GB IDE drive will hold at least 240 CDs in.wav format and around 370 (conservatively) in.shn format. Last time I checked they sold for well under US$200.
A media client that does not support remote content formats in the same way that it supports local content is just plain dumb: there's no reason for it not to.
Furthermore, my desire for a media client that supports.wav or.shn files over the network in no way detracts from your enjoyment of one that only supports lossy compressed formats like MP3. I raised the issue because I know many who would find the lack of support for non-lossy formats, like me, a major issue.
Without mentioning how they were encoded, this is absolutely meaningless.
Honestly, I don't know. "As well as possible" given the tools available. Both of us were considering compressed storage of our music collections at a time where the "sweet spot" price-wise for disks was at the 25 Gb point. In the end we both waited until 100 Gb disks became common, and chose.shn as the format of choice.
Perhaps encoders have improved since then. (I do recall something about 256 Kb/s being the "best", not 320). But as storage is relatively cheap, good encoders missed the window of market opportunity as far as high-fidelity storage is concerned.
You most certainly claimed to have golden ears, as you claimed that you can hear things which are beyond human capability to hear.
Using the expression golden ears does not bother me, but quoting it thus: "golden ears", and putting those words in my mouth does. You chose them, I did not. I know people with golden ears and perfect pitch. They are uncanny.
Although many people claim that they can hear the difference between a high-bitrate MP3 (or OGG) and the original, blind listening tests consistently show that they cannot.
My experience has been that this depends greatly on the material. I listen to a lot of experimental music, as well as classical, and synthetic, and find that the more difficult pieces, in terms of dynamic range and transients do not compress well. Also, piano fares badly when MP3ized.
Sorry. When you said, "Given the fidelity of my stereo system, the losses associated with MP3 compression are unacceptable to me" , I made the unwarranted assumption that you meant that the losses associated with MP3 compression were unacceptable to you.
No, that is a correct understanding of my position. Exaggerating that to suggest (by way of quotes, no less), that I claimed to have "golden ears" and a "gigantic stereo system", is unwarranted. My ears aren't golden, but they aren't tin either.
I'll do the "careful work" for you:
lame -b 320
And when lame encounters something that compresses badly (all compression algorithms have weak spots), what then? Discovering that after the fact is like using a photocopier that leaves a black streak in the margins blindly to copy an important document to send to a friend, only to find out that the margin notes were really important. It is not a risk I find acceptable.
Using MP3 as a format for on-line storage of one's music collection in an age where 100 Gb disks (that can hold almost 200 CDs uncompressed, around 300 with.shn) are cheap, and home networks approach 100 Mb/s is being penny-wise and pound foolish. It is handy in bandwidth- or storage-constrained applications, or when fidelity does not matter.
MP3-compressed cymbals, thunderclaps, and pipe organs are painful to listen to.
Your statement "What few MP3s I've heard came from web site listings a while ago" contradicts your claim that you have ever done a blind listening test.
Obviously, the origins of the material were revealed after the test: I had a friend make a CD of some original as well as compressed and subsequently decompressed music. Which were processed was not made known to me (or him, as he had a program randomly pick selections from processed and unproceessed directories to assemble the compilation, reporting the selections made to a file neither of us saw until after the listening test). Some of the selections on the CD came from one set, the other set, or both sets, encoded at the highest rates available.
The idea was to try to identify the compressed music. While we could not tell on some pieces, on others it was obvious, and that was bad enough for me. I did not consider this test as part of my casual listening experience.
"What's the point of having lossless originals if you can't play them back as they are?"
There's no point in having the lossless originals in the first place.
Beside the fidelity debate, there is a damn good reason: to prove that you have a legitimate license to the copyright music. In Canada at least, I can transcode copyright material in any form I wish but must be able to show that I own a copy of authorized distribution media. This means the original CDs.
In the end, nobody cares if you decide to store all your music as wav files. But if you're going to make assertions such as "to not support.wav files is a travesty", or claiming that MP3s are for "transcoding of legacy audio cassettes", without being able to back it up, you deserve some ridicule.
My not liking the hit and miss nature of the effectiveness of phsycoacoustic compression algorithms is good enough reason to shun MP3 as my main music format. Given that any device that can decode MP3s can surely accomodate.wav files, storage and bandwidth constraints notwithstanding, it IS a travesty to support the former and not the latter.
Compression and fidelity tradeoffs should be a choice, not a requirement unless severe constraints exist.
Fortunately, there are other manufacturers that support uncompressed audio as well as MP3 in their thin media clients.
In the end I decide where my disposable dollars go when it comes to chosing what media thin clients I might purchase, and support for.wav audio is an important consideration for me, and others as well.
So you downloaded a few MP3s off Kazaa that some idiot encoded at 128 kbps with a crap encoder, could tell that the sound quality was lower,
Never used Kazaa in my life. What few MP3s I've heard came from web site listings a while ago, or were passed on to me. When looking at the format, It wasn't obvious what compression options or encoders would be generally good enough, without having to encode a piece of music and decide if it was O.K. Far easier to buy enough disk space and just store.wav or.shn files.
... and therefore concluded that "with my golden ear and gigantic... stereo system, I can tell the difference between any lossless and lossy compressed music."
Now this exageration and misquote of my simple claim to not want to feed typical MP3s (poorly or hastily encoded) to my stereo for concerns of fidelity is not warranted. I never claimed to have "golden ears" or a "gigantic stereo system". FWIW, I drive a pair of Bohlender-Graebner Radia 520s, crossed to a custom Acoustic Visions subwoofer employing a Hypex HS200 plate amp. The main speakers are driven by a Carver TFM-22 amp, and Bang & Olufsen preamp. Some friends consider this rarified compared to their setups and I can clearly hear problems with MP3s on what they own as well as my gear.
While I do not dispute the claim, that with careful work, one could encode an MP3 from a.wav file that was indistinguisible from the original on the equipment I have, I just don't want to spend that much time ripping music. I know I lose nothing with.wav or.shn and don't worry about the issue of fidelity.
Do us all a favor and do a blind listening test, where you will find that you can't tell the difference.
I have, I could, and the MP3s sucked. Even allowing for crappy encoding, this does not remove the problem of having to take care to "properly" encode each piece of music to avoid artifacts, selecting a "good enough" bitrate, etc. I just don't want the hassle.
MP3s have their place: for transcoding of legacy audio cassettes for example (Divx is the equivalent for VHS tapes), but not as a storage and playback format for the music I already have on CDs.
If you're that set on having the lossless originials, you could always write a trivial script that streams an mp3 stream from your wav music on the fly, and use this device.
What's the point of having lossless originals if you can't play them back as they are?
Well, most people want to be able to play back media that they haven't yet copied to their home server, or don't want to (rented DvDs, for example). So, there is a demand for SOME kind of DVD/CD player in the family/media/living room.
Most DVD players are sufficiently cheap that this can qualify as an "upgrade", leaving the old one for the kids. That way, you get additional funcitonality without yet another box.
Why throw anything away on the assumption it's inaudable if one is willing to trade disk space and intranet bandwidth in order to not make that assumption? The choice should be on the part of the user, methinks.
Besides, I've heard enough MP3s, to be turned off from the format, though I have no doubt that they can provide adequate fidelity in many applications.
I can understand the lack of support for.shn files (losslessly compressed audio), but to not support.wav files is a travesty: I have all my music stored as.shn files (and would consider either.wav or a real-time converting server), on my home server. Given the fidelity of my stereo system, the losses associated with MP3 compression are unacceptable to me (and yes, I'm happy with requiring 16-12 times or so the disk space on the server).
These kind of devices should have a standard architecture that supports plugins for new, emerging, and custom media formats (Oh wait! That would defeat the built-in obsolescence). Even if the plugin architecture were platform-specific and not platform-agnostic (somehow, Ogg-Theora (or whatever the Ogg video format is) decoding in Java is likely to be, less than spectacular, perfornace-wise). it would be a start. The next step is a standard API for plugins, and, perhaps, manufacturer-supported remote compilation for each platform.
Otherwise, we won't get the kind of upgradability we'd like without the platform being completely open.
What you need is to do the graphics overlay in the video chip that drives the TV (which could, of course, have component inputs and possibly support HDTV). That's how all the Set Top Boxes do it.
ATI makes a chip designed for this purpose (disclaimer, I work for ATI, but do not speak for them): it's part of the Xilleon series (search http://www.ati.com for Xilleon). Basically, it's a processor, hardware MPEG decoder (or several), video scaler, digital overlay, and output encoder. It supports a graphic overlay mechanism in the digital domain.
Oh yeah, it runs fanless.
Unfortunately, I can not provide any technical information about this chip. However, if there was sufficient interest in the open source and free sofware communities, perhaps ATI might respond to such interest.
"for all intensive purposes" - It's "for all intents and purposes", dipwad.
"quote... unquote". There is no such thing as "unquote" -- it's "end quote". Using "quote unquote" as a prefix to the purported quote is doubly irritating.
"It's like this...." I don't give a blinking fuck what it's like, I want to know what it is.
People who mess up the meanings of precision and accuracy tick me off. 165.04452 +/= 50 is precise, but not very accurate. Abuse of significant digits is another irritant.
The US has lower taxes than we do, but they also have a deficit this year alone larger than our entire national debt.
You're comparing grapes with watermellons: the U.S. economy is much larger than that of Canada (and swings more wildly). Taming the U.S. deficit will be trivial as the economy there continues to improve.
While the tax regimes are fairly close, you'll find more taxes levied "closer to home" in the U.S.: at the county level, mostly for education. This has the effect of encouraging efficiency in the use of tax dollars, since it is relatively easy to move from a high-taxed county to a lesser-taxed one (particularly for people for whom the difference is significant). Also, the U.S., federally, is more focused on self-sufficiency (i.e. home-owner rather than tennant) and family-centricity in it's tax regimes: mortgage interest is deducatable, and single-income families can file jointly.
Living expenses tend to be higher, but the lower taxes offset this and then some. The bottom line is that you get a far greater say in how you spend your earnings, and even large corporations have to compete for them.
If I saw efficiency in the use of tax dollars in Canada, I wouldn't be so brutal in my condemnation of the place -- you'd think that economies of scale would do wonders in areas of insurance and health care, Alas, they don't -- the corruption power brings is too strong to be overcome by basic economics.
As for Manitobans being "stupid" for not moving, that is not effective: the federal system of transfer payments ensures that the better-run provinces continue to fund the inefficiencies in the worse-run ones. Ask Albertans about their oil revenues sometime. There is no incentive for any province to try to compete to offer a better lifestyle.
Slashdot Mirror
I had worked in the U.S. from 1997 to 1999 on a succession of NAFTA TN1 visas (two), after which my employer petitioned and received an H1B for me. I later received an LC in preparation for a Green Card, but, having to change employers, that fell through -- the H1B was successfully transferred though (this used to be a real hassle, but is less so).
The telecom bust had me return to Canada in 2003 -- the H1B was long in the tooth anyway (it's good for three years max., renewuable once, for a total of six, with special excemptions on a year over year basis if you're in the last stage of Green Card processing).
This site is one of the best I found on the subject.
Issues you will face:
1. establishing a U.S. credit history -- it was easier for me to buy a house than get a credit card for the first 12 months (mortgage lenders will be willing to do international credit checks);
2. severing Canadian tax residency -- you WILL want to do this as you will likely not be able to afford to pay Canadian-rate income taxes with U.S. expenses as well;
3. Ignoramii (ignoramuses?) -- everyone will be giving you tax and INS-related advice. Unless it comes from a tax expert or immigration lawyer, IGNORE IT -- there is lot's of missinformation around. Educate yourself -- sometimes the lawyers don't even remember everything.
4. SSN -- this is a slam dunk if you have a job, as you will need one to pay social security taxes. You will need an address... staying in a hotel for a while might be a problem. This will be more of a problem for your dependents -- for tax purposes they can get an ITIN, but some states require an SSN to issue a drivers license. There is a provision that you can get an SSN if a local government requires it -- my wife got one because she needed it to get a drivers' license in Illinois.
5. INS relationships -- let your lawyer handle things, but keep up to date on what they are doing. At the border, make sure you have your paperwork in order, have an extra copy for the INS officer to file if he or she wants, and remember, on a NAFTA TN1 visa, you are a Resident of Canada for U.S. immigration purposes and a U.S. non-resident. This, despite the fact that you will likely be a U.S. resident for tax purposes. Do not, under any circumstances, confuse the two when the INS officer asks, and do not explain the difference -- they care about immigration issues only.
Call the port of entry at the airport to find out what the best time to be processed is -- do not show up five minutes prior to your flight.
Do not lie to a U.S. immigration officer, but don't volunteer anything beyond what you're asked either.
Finally, Good Luck!
I thought letters patent relied on the support of provincial and not federal legislation in Canada.
Though, in my case, the buyers' preferred lender refused the buyers' lawyer acting via a POA and they eventually had to do a cash closing.
I had the wonderful experience of using the U.S. consulate in Toronto for one of the oldest raison d'etre (reasons for being, literally) of U.S. consulates: verifying the authenticity of signatures on U.S. legal documents.
IIRC, the Open Source Definition does not permit a license to discriminate against a "field of endevour".
So, of course, Open Source (and Free, for that matter) software can be used for "bad" things.
But, many things can be used for "bad" things. The user, and not the creator, are responsible here (unless, of course, the creation was aimed specifically for a particular use, but then you run afoul of discriminating against other uses).
Since "good" vs. "bad" is in the eyes and mind of the beholder, or, all too often, enforced by some authority, it is probably a good thing that OSS does not permit discrimination on the basis of a field of endevour.
I think Bruce Perens uses the example of abortion clinics and anti-abortionists: both are welcome to use Open Source software.
Such clauses are generally unenforcable in the extreme. For a contract to be enforcable (i.e. for Comcast to take your money in the first place), there has to be "valuable consideration".
Contracting to exchange money for no service after advertising a service is fraud. At least the customer can't be held to pay. But, the customer does have a reasonable expextation to get something for the money they have agreed to spend.
Also, "no guarantee" is not the same as "service disconnection". In contract law, (and no, IANAL), there is the concept of "performance", that is, both parties must take reasonable efforts to perform as per their agreements. In this case, Comcast is expected to proivide internet access "much better and faster" than dial up (my quotes), that appears "unlimited", i.e. unmetered.
Their lack of a guaranteed level of service generally protects them against service interruptions, rather like when the coax to your home from the cable company breaks. Even then, they have to refund your money for service not provided. But, again, disconnection for abuse is not a service interruption.
It is reasonable for Comcast to set use limits. It is reasonable for them to throttle customers who consistently exceed them. It is not reasonable for them to advertise no limits and take harsh measures (disconnection with no means to reconnect) when some unspecified limits are exceeded.
A judge would likely look at what "unlimited" means in the market place of DSL or Cable modem internet service. It generally means, "as much as will satisfy 90, 95, or 99% of the customer base, given that the resource is not, in fact, unlimited". In other words, practically unlimited.
Every ISP I have ever dealt with that offered unlimited service made it clear that they meant "practically unlimited", and when limits were not clearly established, had a published, and rather gentle policy for dealing with causing excessive traffic that affected other customers, usually, something along the lines of "you used up this much bandwidth, that's too much, you should use less than this much over a month, here's how you can monitor it. If it happens again, we'll have to drop you, or you'll have to pay for a specified service level." They also generally have means to help the customer ensure that they do not exceed these limits: throttling them harshly when they've exceeded their monthly quota.
It's quite another to claim service is unlimited and then sever it because some unspecified limit was reached. Severing service is not the same as throttling it, and thottling it unreasonably (say, to 1 b/s) is effectively severing it, if you think you can be a smartass with semantics.
A reasonable response, when there is no guarantee of service, would be forced throttling to average customer base limits within short order of detecting "excessive" traffic for a prolonged period, lightening up on burstiness over time.
No customer can be reasonably expected to keep their use "in check" when they do not know what the limits are. This is not a criminal issue where the police are not required to advertise how fast beyond the speed limit you can drive before they stop looking the other way. This is a contractual dispute, and when there is doubt as to the meaning, they tend to settle against the drawer of the contract.
Of course, if Comcast was smart and clearly disclaimed what they meant by "unlimited", I'd side with you. But, I get the impression that their marketting department got ahead of their technical and legal departments on this one.
If that's the case, and their customer contracts permit them to unilaterally change TOS (permitting cancellation without penalty), then that's what they should do: redefine TOS to eliminate vague references to unlimited service. Even if they were in the right, legally, acting heavyhanded toward your customers is not a good way to keep them.
While technically correct, this is stretching the meaning of "potentially" to probabalistic extremes with which I am not familiar.
The reason for this is that, as the party drawing the contract, they can word it in the best possible way for themselves. That they did not, when they had the chance, is, as we used to say as kids, "tough nookies".
This is why you have your lawyer draw contracts that you propose.
Business that say "unlimited" when the service is not unlimited are guilty of fraud.
But, I was thinking of a separate address space for each object allocated within an object-oriented paradigm. No more falling off the end of arrays, or mis-casting pointers. I'd expect performance to suck, of course, as virtual memory tables get changed on each pointer dereference, but, one can dream.
No, I was thinking of small object allocators. Think dynamic memory allocation where you want to allocate, say, two bytes or even one dynamically, and you need a bunch of them.
Well, a traditional allocator generally maintains a doubly linked list (or other structure) of allocated or available blocks. This overhead swamps out the size of the small object you need and is grossly inefficient.
What you do, is not allocate one or two bytes at a time, but a medium-sized block of several hundred (or dozens if the block size is 10 bytes or so) in one fell swoop, and then allocate out of that smaller blocks of a given size (programs usually only deal with blocks of a small number of different known sizes).
Now, keeping track of the free small blocks within the larger blocks will involve making a linked list, yes? (well, you could use a bitmap, but that has 12.5% overhead if allocating 8 bit bytes). But, in each larger block, you only have a small number of smaller blocks, and counting (or indexing) them does not require big, wide 32 or 64 bit pointers. An example might help.
Consider an allocation where you need to dynamically allocate single eight bit bytes. You allocate a block of 255 of them, and use the numbers 1 to 255 to index them. Gee, that kind of number fits in a single byte, so you link the free list within the block that way. The only complication arises when returning a byte to the free list: which larger 255 byte block did it come from? Well, you can maintain a table of block starting addresses, and search within it to find the larger block from whence it was allocated. It helps a bit if you allocate the 255 byte blocks on 256 byte boundaries (waste a byte to contain the index to the head of the free list).
Now, searching the table of larger blocks allocated is an O(log n) operation, and returning a byte to it's correct block is an O(1) operation. Allocation is O(1): you keep a list of larger blocks of the same size.
Andrei Alexandrescu has an excellent chapter on small object allocators in his book, "Modern C++ Design".
Exactly!
Except, we haven't done that yet. That's the "speed bump" to which I alluded.
Now, others have pointed out that storing more smaller bits in cache uses, well, less cache, but I'd counter that more pointer in cache increases the chance that you'll reference something out of cache and the likelihood of going out to slow DRAM. So, there's a case where smaller pointers are going to bite you, not because they're smaller though, but because you're managing so many pointers (and keeping them small for storage reasons), that your all is probably vectoring (code- or data-wise) all over the place.
Look, there will always be some application where you have to tailer the algorithm and data structures to the details of the hardware. Been there, done that. But, in general 64 bit pointers on a post-modern processor (with bigger caches, memory, etc.) will be "as fast as" 32 bit pointers on a modern machine, or 16 bit pointers on a legacy machine, or 16 bit pointers on an 8080 (which had an 8 bit data bus). Faster, actually, because of all the other speedups.
But, the very first bleeding edge move from 32 to 64 bits will likely come with a performance penalty.
Me, I like to code Foo*, i.e. pointer to Foo, and let the compiler do the right thing. Having a switch to globally control the compiler is probably a good idea. But, having my share of "near" and "far" pointers in the old segmented architecture days of the 8086/8088/80286 was painful. Of course the hit between a near and far pointer was far worse then because of the segmentaton issue. Then again, who knows how many virtual address lookup tables you'll have with a 64 bit address space.
Really, if you had the time, you'd make your optimizations conditional, and wait for the rest of the system to do a better job than you do.
So, memory bandwidth remains an issue, and I concede the point.
Still, buse widths tend to optimize around typical transfer patterns, and pointers tend to grow to to be "always big enough" -- the cases where we tailor pointers to be within smaller constraints are quite specilized. It's more convenient to have one pointer size -- does anyone remember the four memory models that Microsoft C compiler used to support (probably still does)? tiny (16 bit data and code pointers), small (16 bit data, 32 bit code, IIRC), large, and huge? 'Course that isn't a perfect comparison because of the brain dead segmented x86 memory architecture, but you get the idea. It was (is) a pain.
But, bus widths and memory capacities will grow to the point where the 64 bit code of tomorrow will be as fast as the 32 bit code of today, and the need to optimize further will occur only in esoteric bits of code.
Besides, with 64 bits, you can do fun things, like allocate different objects in different virtual memory spaces and use the memory management system to catch wild-pointer bugs (because no two different objects need be adjacent in the logical memory space).
On the whole the advantages outweigh the disadvantages, and the performance penalties will be moot quite shortly.
*cough* wider data busses *cough*. 'course this does mean that 64 bit code on systems with 32 bit wide data paths will be slower, but, like, migration always involves speed bumps. I remember the a.out to elf transition pain days of Linux.
The whole point of a networked media client is to avoid having to have all one's media close to it. CDs get heavy and the space they take up adds up.
Or Make a Music CD from the wav or shn file and THEN put the CD in the DVD player and shut the hell up!
So, when I want to listen to something, I have to first burn a CD, and then take it to the media client? I'm too much of a couch potato for that: if I'm in the mood for Pink Floyd, I want to select Pink Floyd from the menu on the TV or webpad and go from there.
If the original "lossless" files then you can skip the mp3 format all together and leave those of us without terabytes of storage space to enjoy out music libraries in peace.
Terabytes? a 160 GB IDE drive will hold at least 240 CDs in .wav format and around 370 (conservatively) in .shn format. Last time I checked they sold for well under US$200.
A media client that does not support remote content formats in the same way that it supports local content is just plain dumb: there's no reason for it not to.
Furthermore, my desire for a media client that supports .wav or .shn files over the network in no way detracts from your enjoyment of one that only supports lossy compressed formats like MP3. I raised the issue because I know many who would find the lack of support for non-lossy formats, like me, a major issue.
Honestly, I don't know. "As well as possible" given the tools available. Both of us were considering compressed storage of our music collections at a time where the "sweet spot" price-wise for disks was at the 25 Gb point. In the end we both waited until 100 Gb disks became common, and chose .shn as the format of choice.
Perhaps encoders have improved since then. (I do recall something about 256 Kb/s being the "best", not 320). But as storage is relatively cheap, good encoders missed the window of market opportunity as far as high-fidelity storage is concerned.
You most certainly claimed to have golden ears, as you claimed that you can hear things which are beyond human capability to hear.
Using the expression golden ears does not bother me, but quoting it thus: "golden ears", and putting those words in my mouth does. You chose them, I did not. I know people with golden ears and perfect pitch. They are uncanny.
Although many people claim that they can hear the difference between a high-bitrate MP3 (or OGG) and the original, blind listening tests consistently show that they cannot. My experience has been that this depends greatly on the material. I listen to a lot of experimental music, as well as classical, and synthetic, and find that the more difficult pieces, in terms of dynamic range and transients do not compress well. Also, piano fares badly when MP3ized.
No, that is a correct understanding of my position. Exaggerating that to suggest (by way of quotes, no less), that I claimed to have "golden ears" and a "gigantic stereo system", is unwarranted. My ears aren't golden, but they aren't tin either.
I'll do the "careful work" for you:
lame -b 320
And when lame encounters something that compresses badly (all compression algorithms have weak spots), what then? Discovering that after the fact is like using a photocopier that leaves a black streak in the margins blindly to copy an important document to send to a friend, only to find out that the margin notes were really important. It is not a risk I find acceptable.
Using MP3 as a format for on-line storage of one's music collection in an age where 100 Gb disks (that can hold almost 200 CDs uncompressed, around 300 with .shn) are cheap, and home networks approach 100 Mb/s is being penny-wise and pound foolish. It is handy in bandwidth- or storage-constrained applications, or when fidelity does not matter.
MP3-compressed cymbals, thunderclaps, and pipe organs are painful to listen to.
Your statement "What few MP3s I've heard came from web site listings a while ago" contradicts your claim that you have ever done a blind listening test.
Obviously, the origins of the material were revealed after the test: I had a friend make a CD of some original as well as compressed and subsequently decompressed music. Which were processed was not made known to me (or him, as he had a program randomly pick selections from processed and unproceessed directories to assemble the compilation, reporting the selections made to a file neither of us saw until after the listening test). Some of the selections on the CD came from one set, the other set, or both sets, encoded at the highest rates available.
The idea was to try to identify the compressed music. While we could not tell on some pieces, on others it was obvious, and that was bad enough for me. I did not consider this test as part of my casual listening experience.
"What's the point of having lossless originals if you can't play them back as they are?"
There's no point in having the lossless originals in the first place.
Beside the fidelity debate, there is a damn good reason: to prove that you have a legitimate license to the copyright music. In Canada at least, I can transcode copyright material in any form I wish but must be able to show that I own a copy of authorized distribution media. This means the original CDs.
In the end, nobody cares if you decide to store all your music as wav files. But if you're going to make assertions such as "to not support .wav files is a travesty", or claiming that MP3s are for "transcoding of legacy audio cassettes", without being able to back it up, you deserve some ridicule.
My not liking the hit and miss nature of the effectiveness of phsycoacoustic compression algorithms is good enough reason to shun MP3 as my main music format. Given that any device that can decode MP3s can surely accomodate .wav files, storage and bandwidth constraints notwithstanding, it IS a travesty to support the former and not the latter.
Compression and fidelity tradeoffs should be a choice, not a requirement unless severe constraints exist.
Fortunately, there are other manufacturers that support uncompressed audio as well as MP3 in their thin media clients.
In the end I decide where my disposable dollars go when it comes to chosing what media thin clients I might purchase, and support for .wav audio is an important consideration for me, and others as well.
Never used Kazaa in my life. What few MP3s I've heard came from web site listings a while ago, or were passed on to me. When looking at the format, It wasn't obvious what compression options or encoders would be generally good enough, without having to encode a piece of music and decide if it was O.K. Far easier to buy enough disk space and just store .wav or .shn files.
Now this exageration and misquote of my simple claim to not want to feed typical MP3s (poorly or hastily encoded) to my stereo for concerns of fidelity is not warranted. I never claimed to have "golden ears" or a "gigantic stereo system". FWIW, I drive a pair of Bohlender-Graebner Radia 520s, crossed to a custom Acoustic Visions subwoofer employing a Hypex HS200 plate amp. The main speakers are driven by a Carver TFM-22 amp, and Bang & Olufsen preamp. Some friends consider this rarified compared to their setups and I can clearly hear problems with MP3s on what they own as well as my gear.
While I do not dispute the claim, that with careful work, one could encode an MP3 from a .wav file that was indistinguisible from the original on the equipment I have, I just don't want to spend that much time ripping music. I know I lose nothing with .wav or .shn and don't worry about the issue of fidelity.
Do us all a favor and do a blind listening test, where you will find that you can't tell the difference.
I have, I could, and the MP3s sucked. Even allowing for crappy encoding, this does not remove the problem of having to take care to "properly" encode each piece of music to avoid artifacts, selecting a "good enough" bitrate, etc. I just don't want the hassle.
MP3s have their place: for transcoding of legacy audio cassettes for example (Divx is the equivalent for VHS tapes), but not as a storage and playback format for the music I already have on CDs.
If you're that set on having the lossless originials, you could always write a trivial script that streams an mp3 stream from your wav music on the fly, and use this device.
What's the point of having lossless originals if you can't play them back as they are?
Most DVD players are sufficiently cheap that this can qualify as an "upgrade", leaving the old one for the kids. That way, you get additional funcitonality without yet another box.
Besides, I've heard enough MP3s, to be turned off from the format, though I have no doubt that they can provide adequate fidelity in many applications.
These kind of devices should have a standard architecture that supports plugins for new, emerging, and custom media formats (Oh wait! That would defeat the built-in obsolescence). Even if the plugin architecture were platform-specific and not platform-agnostic (somehow, Ogg-Theora (or whatever the Ogg video format is) decoding in Java is likely to be, less than spectacular, perfornace-wise). it would be a start. The next step is a standard API for plugins, and, perhaps, manufacturer-supported remote compilation for each platform.
Otherwise, we won't get the kind of upgradability we'd like without the platform being completely open.
ATI makes a chip designed for this purpose (disclaimer, I work for ATI, but do not speak for them): it's part of the Xilleon series (search http://www.ati.com for Xilleon). Basically, it's a processor, hardware MPEG decoder (or several), video scaler, digital overlay, and output encoder. It supports a graphic overlay mechanism in the digital domain.
Oh yeah, it runs fanless.
Unfortunately, I can not provide any technical information about this chip. However, if there was sufficient interest in the open source and free sofware communities, perhaps ATI might respond to such interest.
"quote... unquote". There is no such thing as "unquote" -- it's "end quote". Using "quote unquote" as a prefix to the purported quote is doubly irritating.
"It's like this...." I don't give a blinking fuck what it's like, I want to know what it is.
People who mess up the meanings of precision and accuracy tick me off. 165.04452 +/= 50 is precise, but not very accurate. Abuse of significant digits is another irritant.
You're comparing grapes with watermellons: the U.S. economy is much larger than that of Canada (and swings more wildly). Taming the U.S. deficit will be trivial as the economy there continues to improve.
While the tax regimes are fairly close, you'll find more taxes levied "closer to home" in the U.S.: at the county level, mostly for education. This has the effect of encouraging efficiency in the use of tax dollars, since it is relatively easy to move from a high-taxed county to a lesser-taxed one (particularly for people for whom the difference is significant). Also, the U.S., federally, is more focused on self-sufficiency (i.e. home-owner rather than tennant) and family-centricity in it's tax regimes: mortgage interest is deducatable, and single-income families can file jointly.
Living expenses tend to be higher, but the lower taxes offset this and then some. The bottom line is that you get a far greater say in how you spend your earnings, and even large corporations have to compete for them.
If I saw efficiency in the use of tax dollars in Canada, I wouldn't be so brutal in my condemnation of the place -- you'd think that economies of scale would do wonders in areas of insurance and health care, Alas, they don't -- the corruption power brings is too strong to be overcome by basic economics.
As for Manitobans being "stupid" for not moving, that is not effective: the federal system of transfer payments ensures that the better-run provinces continue to fund the inefficiencies in the worse-run ones. Ask Albertans about their oil revenues sometime. There is no incentive for any province to try to compete to offer a better lifestyle.