In the US, the cell phone user has to use up minutes to use the cell phone, whether he or she is making or receiving a call (which involves paying if the pre-paid minutes included in the monthly plan are up). The caller does not pay if it's a local call. At all. Not even a cent.
In Europe, on the other hand, it's disgusting -- if you make a call to a cell phone, you have to pay an exorbitant extra fee over the normal cost to dial a land-line. This is ridiculous -- if the other guy wants a cell phone, let him pay for it. I shouldn't have to pay extra because he chose to use a cell phone instead of a land-line. (The way I get around this at the moment is just to refuse to call people in Europe unless they give me a landline number to call.)
The rates for G3 are incredibly high, so much so that they're beyond affordability for many in the US and Europe, let alone India. Someone using a mere 10 MB/month (which is something like 15 mins/day of websurfing) would have a phone bill of over US$200/month. That's ridiculous.
That's just transcoding, can be done with any format (or even between formats), and is generally a very bad idea. The point of bitrate peeling is to allow you to do 128->64 and end up with a 64 that sounds not too much worse than a 64 that was encoded straight from the original source material. Doing a 128->64 transcoding (which is really 128->wav->64) will give you something that sounds significantly worse than straight-to-64.
I've heard that it's supposed to be better, but I haven't seen any listening tests that show that to any significant extent. IIRC, the latest iteration (gt beta 3) turned out to have some pretty major quality problems with it, and that's unlikely to change in the near future, as garf has discontinued work for the moment.
In any case, it's not nearly enough tuning to match the tuning done on the LAME mp3 encoder, which is why at high quality levels Ogg remains approximately even with MP3, despite MP3's inherent suckiness as a format.
VBR MP3 not only exists, but is quality (not bitrate) based, and very widely used amongst the sort of people who care about quality (including several major filetrading networks). Tthere is also average-bitrate VBR, but this is not the recommended one: LAME's --alt-preset standard is recommended, and is a quality-based mode. It is generally considered approximately equal quality-wise to Ogg -q6 (and averages around the same bitrates as Ogg -q6 as well).
So I maintain my point, that Ogg is not superior to MP3 at high bitrates (or "high quality settings" if you prefer, which maps to the same thing). Once you get above Ogg -q4 or so, MP3 can match Ogg's quality at similar filesizes.
It is not generally agreed that LAME APS Ogg Q6. Q6 should in theory be better than APS, but APS is much better tuned at the moment, so the quality is roughly comparable (they fail on different samples, in different ways).
This is only true if you use very low bitrates (i.e. Vorbis 16 kbps *might* be close to MP3 32 kbps). It's certainly not true at most bitrates. Usually a 5-30% gain is more reasonable, decreases as bitrates get higher (since Vorbis is currently really well-tuned only up to 128 kbps or so).
You can't expect much more than 5 Mbps because around 5.5 Mbps is the theoretical bandwidth. Quoting 11 Mbps is highly misleading, as this is merely the signalling rate; there is some overhead in the physical-level protocol. If this sort of misleading labelling were used by ethernet, 100 Mbps ethernet would be advertised as 125 Mbps (the signalling rate is 125 Mbps, but it needs 5 bits for each 4 bits of real data transferred).
So yes, I think it's bad to market 11b at 11 Mbps or 11g at 54 Mbps, as these are not their throughputs; they should be marketed at 5.5 Mbps and 22 Mbps, respectively.
At my school, only the freshman lectures that everyone (non-cs majors included) has to take are at 8 or 9am (more commonly 9am). Any CS class past that is 11 or later, with 1:15 being the most popular timeslot.
At least many liberal arts professors know they have nothing better to do than meet with students (ok, maybe you're writing a book, but certainly that can wait an hour). Most science profs, on the other hand, are "too busy researching" on big NSF grants to bother spending any time at all teaching or meeting with students (except perhaps their PhD students, since they're the ones doing all the actual work).
I find my professors all the time, sometimes at 10pm, sometimes at 1am. They're likely to be in their office at the very least anytime 10am-5pm except during lunchtime and when they're actually teaching classes. Of course, I go to a college with no grad school and hence no TAs to do their teaching for them (or big research grants to take up their time)...
I agree that it can be misused, but I think tenure is on the whole very positive. It's to protect academic freedom, but this goes deeper than you might imagine. It's not just to allow controversial research to continue without the professor being pressured into reaching desired conclusions (though that is an important part of it), but also to allow important research to happen at all with education and advancement rather than money in mind. Without a tenure system, it's quite likely that professors would be pressured only to do research that would directly bring money to the university (whether in grant money or in patent licensing).
I've occasionally gone down to the CS department at 9am and found every single door shut, as the faculty hadn't rolled out of bed to come in to work yet. At 1am, meanwhile, you'll always find at least one prof. still there...
I'm not an expert on the current system, but I wouldn't think that currently your bill being damaged so that the serial # is unreadable is grounds for not accepting it as legal tender.
Damaged currency is legal tender in almost all countries. A dead RFID, a corner ripped off, a hole in the middle, etc. Given that a certain percentage will die anyway, there's really no other choice -- they can remove currency with a dead RFID from circulation, but they can't reasonably declare it counterfeit.
Damaged bills are still legal tender in almost all countries. In the US the only criterion is that it be identifiable and more than half the bill (to keep you from ripping them in half and doubling your money). Some percentage of RFID chips will likely die naturally anyway, so there's no way they could invalidate your money if their chip happens to die. The next bank that touches it may wish to take it out of circulation, but that's something else entirely (akin to taking heavily-worn bills out of circulation).
I agree somewhat with that approach, and am personally glad it's the one I took, but in some ways it defeats the purpose of the high-level abstraction. The point of abstracting memory management is not that you already know what's going on under the hood, but that you should be able to code at a high-level and let the compiler worry about what's going on under the hood. Ideally you would have no idea what was going on, though in practice this isn't entirely possible (since often you have to put implementation considerations into your high-level programming since compilers aren't yet good enough to optimize everything well).
Note though that C being "low level" is somewhat relative -- if you're running on a Lisp machine (where Lisp's primitives are implemented in hardware), then Lisp is low-level.
I probably wouldn't use C# either, primarily for that reason. I do think it's good as a language though, and would be happy to consider using it if there were a free/standard implementation of it (like C++'s STL libraries, though hopefully a little less ugly).
Not just from its libraries
on
Hijacking .NET
·
· Score: 1
Even as a language, C# is pretty interesting. Like Java, it basically tries to fix C++, and I think it does it in a way that in at least some cases is better than the way Java does it. Properties, delegates, events, and the parameter-passing modes are all interesting language features that I could see as being useful (and more elegant than the C++ analogues).
it's a programmer's tool, not a security tool
on
Hijacking .NET
·
· Score: 1
In the basic OOP model, private variables are a tool for the programmer, not a security tool -- they're there to prevent inadvertant private accesses, not malicious ones (that is, the programmer can't accidentally muck around with internals of a class that'd cause it to break, because the compiler won't let him). So the goal isn't to make it impossible, only hard enough that you can't do it accidentally.
So unless you're in a mode where there is a security layer added (which the parent poster mentioned.NET seems to have), there's no reason your system necessarily needs to catch at runtime funny things that result in accessing private members (unless that's part of the language specification, e.g. Java).
I think he was referring to performance
on
Hijacking .NET
·
· Score: 1
The post he was responding to mentioned that Java was designed to provide this safety without impacting performance. The poster you responded to was most likely referring to Java's notorious slowness.
Sure, it's a European standard, but unless Japan, Korea, and the U.S. are no longer part of the world, GSM is not a world standard. Especially since those three countries make up a huge percentage of high-tech business.
CDMA is the standard in the US, GSM is the standard in Europe. In countries that are neither the US nor Europe, things are somewhat divided. Most other countries by raw count use GSM, but some of the most technologically advanced ones use CDMA, which makes the number of sets in circulation fairly close. In particular, Japan and Korea both use CDMA, so unless the combined populations of Japan, Korean, and the US are removed from what's considered "the World", you can't call GSM a world standard.
Slashdot Mirror
In the US, the cell phone user has to use up minutes to use the cell phone, whether he or she is making or receiving a call (which involves paying if the pre-paid minutes included in the monthly plan are up). The caller does not pay if it's a local call. At all. Not even a cent.
In Europe, on the other hand, it's disgusting -- if you make a call to a cell phone, you have to pay an exorbitant extra fee over the normal cost to dial a land-line. This is ridiculous -- if the other guy wants a cell phone, let him pay for it. I shouldn't have to pay extra because he chose to use a cell phone instead of a land-line. (The way I get around this at the moment is just to refuse to call people in Europe unless they give me a landline number to call.)
The rates for G3 are incredibly high, so much so that they're beyond affordability for many in the US and Europe, let alone India. Someone using a mere 10 MB/month (which is something like 15 mins/day of websurfing) would have a phone bill of over US$200/month. That's ridiculous.
That's just transcoding, can be done with any format (or even between formats), and is generally a very bad idea. The point of bitrate peeling is to allow you to do 128->64 and end up with a 64 that sounds not too much worse than a 64 that was encoded straight from the original source material. Doing a 128->64 transcoding (which is really 128->wav->64) will give you something that sounds significantly worse than straight-to-64.
I've heard that it's supposed to be better, but I haven't seen any listening tests that show that to any significant extent. IIRC, the latest iteration (gt beta 3) turned out to have some pretty major quality problems with it, and that's unlikely to change in the near future, as garf has discontinued work for the moment.
In any case, it's not nearly enough tuning to match the tuning done on the LAME mp3 encoder, which is why at high quality levels Ogg remains approximately even with MP3, despite MP3's inherent suckiness as a format.
VBR MP3 not only exists, but is quality (not bitrate) based, and very widely used amongst the sort of people who care about quality (including several major filetrading networks). Tthere is also average-bitrate VBR, but this is not the recommended one: LAME's --alt-preset standard is recommended, and is a quality-based mode. It is generally considered approximately equal quality-wise to Ogg -q6 (and averages around the same bitrates as Ogg -q6 as well).
So I maintain my point, that Ogg is not superior to MP3 at high bitrates (or "high quality settings" if you prefer, which maps to the same thing). Once you get above Ogg -q4 or so, MP3 can match Ogg's quality at similar filesizes.
It is not generally agreed that LAME APS Ogg Q6. Q6 should in theory be better than APS, but APS is much better tuned at the moment, so the quality is roughly comparable (they fail on different samples, in different ways).
Bitrate peeling is not yet implemented, and will not be for quite some time.*
* Well, there are experimental implementations, but the quality is generally considered to be unacceptable, so the interfaces are not yet exposed.
This is only true if you use very low bitrates (i.e. Vorbis 16 kbps *might* be close to MP3 32 kbps). It's certainly not true at most bitrates. Usually a 5-30% gain is more reasonable, decreases as bitrates get higher (since Vorbis is currently really well-tuned only up to 128 kbps or so).
You can't expect much more than 5 Mbps because around 5.5 Mbps is the theoretical bandwidth. Quoting 11 Mbps is highly misleading, as this is merely the signalling rate; there is some overhead in the physical-level protocol. If this sort of misleading labelling were used by ethernet, 100 Mbps ethernet would be advertised as 125 Mbps (the signalling rate is 125 Mbps, but it needs 5 bits for each 4 bits of real data transferred).
So yes, I think it's bad to market 11b at 11 Mbps or 11g at 54 Mbps, as these are not their throughputs; they should be marketed at 5.5 Mbps and 22 Mbps, respectively.
You quote raw signal rate and actual throughput for b, but not for g, which is a bit misleading. For those who still haven't figured it out:
b: 11Mbps signalling rate, 4-5 Mbps effective throughput
g: 54Mbps signalling rate, ~22 Mbps effective throughput.
[I don't know anything about a, so I'll let someone else comment about that.]
At my school, only the freshman lectures that everyone (non-cs majors included) has to take are at 8 or 9am (more commonly 9am). Any CS class past that is 11 or later, with 1:15 being the most popular timeslot.
At least many liberal arts professors know they have nothing better to do than meet with students (ok, maybe you're writing a book, but certainly that can wait an hour). Most science profs, on the other hand, are "too busy researching" on big NSF grants to bother spending any time at all teaching or meeting with students (except perhaps their PhD students, since they're the ones doing all the actual work).
I find my professors all the time, sometimes at 10pm, sometimes at 1am. They're likely to be in their office at the very least anytime 10am-5pm except during lunchtime and when they're actually teaching classes. Of course, I go to a college with no grad school and hence no TAs to do their teaching for them (or big research grants to take up their time)...
I agree that it can be misused, but I think tenure is on the whole very positive. It's to protect academic freedom, but this goes deeper than you might imagine. It's not just to allow controversial research to continue without the professor being pressured into reaching desired conclusions (though that is an important part of it), but also to allow important research to happen at all with education and advancement rather than money in mind. Without a tenure system, it's quite likely that professors would be pressured only to do research that would directly bring money to the university (whether in grant money or in patent licensing).
I've occasionally gone down to the CS department at 9am and found every single door shut, as the faculty hadn't rolled out of bed to come in to work yet. At 1am, meanwhile, you'll always find at least one prof. still there...
I'm not an expert on the current system, but I wouldn't think that currently your bill being damaged so that the serial # is unreadable is grounds for not accepting it as legal tender.
Damaged currency is legal tender in almost all countries. A dead RFID, a corner ripped off, a hole in the middle, etc. Given that a certain percentage will die anyway, there's really no other choice -- they can remove currency with a dead RFID from circulation, but they can't reasonably declare it counterfeit.
Damaged bills are still legal tender in almost all countries. In the US the only criterion is that it be identifiable and more than half the bill (to keep you from ripping them in half and doubling your money). Some percentage of RFID chips will likely die naturally anyway, so there's no way they could invalidate your money if their chip happens to die. The next bank that touches it may wish to take it out of circulation, but that's something else entirely (akin to taking heavily-worn bills out of circulation).
I agree somewhat with that approach, and am personally glad it's the one I took, but in some ways it defeats the purpose of the high-level abstraction. The point of abstracting memory management is not that you already know what's going on under the hood, but that you should be able to code at a high-level and let the compiler worry about what's going on under the hood. Ideally you would have no idea what was going on, though in practice this isn't entirely possible (since often you have to put implementation considerations into your high-level programming since compilers aren't yet good enough to optimize everything well).
Note though that C being "low level" is somewhat relative -- if you're running on a Lisp machine (where Lisp's primitives are implemented in hardware), then Lisp is low-level.
I probably wouldn't use C# either, primarily for that reason. I do think it's good as a language though, and would be happy to consider using it if there were a free/standard implementation of it (like C++'s STL libraries, though hopefully a little less ugly).
Even as a language, C# is pretty interesting. Like Java, it basically tries to fix C++, and I think it does it in a way that in at least some cases is better than the way Java does it. Properties, delegates, events, and the parameter-passing modes are all interesting language features that I could see as being useful (and more elegant than the C++ analogues).
So unless you're in a mode where there is a security layer added (which the parent poster mentioned
The post he was responding to mentioned that Java was designed to provide this safety without impacting performance. The poster you responded to was most likely referring to Java's notorious slowness.
Sure, it's a European standard, but unless Japan, Korea, and the U.S. are no longer part of the world, GSM is not a world standard. Especially since those three countries make up a huge percentage of high-tech business.
CDMA is the standard in the US, GSM is the standard in Europe. In countries that are neither the US nor Europe, things are somewhat divided. Most other countries by raw count use GSM, but some of the most technologically advanced ones use CDMA, which makes the number of sets in circulation fairly close. In particular, Japan and Korea both use CDMA, so unless the combined populations of Japan, Korean, and the US are removed from what's considered "the World", you can't call GSM a world standard.