If you can keep up the pace, you can drive by car between any 2 points in the continental US in 72 hours: 60mph * 72h = 4320 miles. If you've got an emergency, you're better off driving, no matter how far
Hmm.
Miami, FL to Anchorage, AK is 5,000 miles by car. Even factoring in the 11-12 hour flight it's still faster to wait 3 days and fly (especially since you're not going to average 60 MPH on that drive).
What is more complicated is to deal with large numbers of concurrent requests. Then you need clustering.
But note that with a good indexer, "large numbers" should be pretty large. We have no problem handling about 500 requests/second for full-text paragraph-level searches of about 1 TB of data on a fairly modest machine. I can't remember the exact details, but it's something like a 1.8 GHz Pentium IV with 512 MB of RAM, and it's got plenty of room to grow (otherwise we'd at least add more RAM).
Failover for availability is certainly nice, but with a decent design it'd be surprising to need clustering for performance until you get well past the "what indexers are out there?" question-asking phase of your data mining career.
(The main thing we use clustering for is full regex searches, but the text indexer and smart caching can be used to make many common applications of those pretty fast as is).
If being an audiophile means having the sort of mindset to remotely accept that as plausible, suddenly I have much less respect for the audiophiles I know.
It doesn't. Most audiophiles are happy with 10 AWG $.57/ft cable with decent banana clips on it (the main concern being corrosion, but we're talking closer to $10 than $100 for a premium cable).
They'll spend decent money on speakers and a nice pair of Grados or Sennheisers, and they'll put curtains over that big glass door in the listening room, but they won't be buying $10,000 CD players with seperate transports and DACs, using green magic markers on the edges of the CDs, putting carbon fiber mats under their cables, buying $500 wooden knobs, or any of that crap.
These people who buy monster (or Pear anjou) cables are as much "audiophiles" as people who are into VTEC stickers, bolt-on hood "scoops", cut-off suspensions, clip-on wings, and so forth are gearheads.
It's not "elitist fuckery", it's a combination of good equipment, an original source recording of high quality, and perhaps better-than-average hearing.
Every actual study I've seen shows that except on certain "hard" classes of recordings it's wishful thinking or other psychology--with 99% of normal music (be it well-recorded classical, a capella voice, rock, whatever) the 256kbps VBR LAME settings Amazon uses haven't been distinguishable to anyone in any scientific study I'm aware of.
I've had this argument many times, and there are some recordings that reveal obvious flaws in even 320 kbps CBR mp3 to my ears with my headphones and amplifier
If you can do it regularly, then you should pretty easily be able to make thousands of dollars for a few hour's work by claiming any of the numerous prizes offered for people who can succesfully distinguish 256kbps VBR MP3 of a wide array of popular music from uncompressed originals in a double-blind A/B test.
Now, if you're just talking a handful of special-case horrible-for-mp3 recordings (like, say, the well-known Eig "LAME killer" sample) then that's another story; some people can certainly pick that one out at 320 kbps VBR.
You can easily start off using a free ABX program like PC ABX (Windows) or LinABX, or a more expensive hardware solution. Just see if you can actually ABX them at home and if so, you should be good to go claim some cash.
It's pretty fun to see what you can actually distinguish, too. I have a nice setup with a good pair of Grados; out of my library of 4000+ songs there are maybe 3-4 I've found so far that I can pick out a 192kbps Ogg from FLAC. Before doing such testing, I was "sure" I could pick out the difference between the original and the 320kbps encodings I usually make. Most people who come over to my place can't distinguish 96 kbps from uncompressed except on a handful of nasty test samples, but if you actually learn what the common artifacts are it gets a bit easier for some people.
More importantly the improved "quality" of 256 kb AAC over 256kb MP3 is largely hypothetical, few if any could tell the difference.
There are sites out there offering decent rewards (in the thousands of US$) to anyone able to tell the difference between 256kb MP3 and uncompressed audio in double-blind A/B tests (of course there are specifications on which version of LAME and options are used for the encoding). I just googled around and couldn't find the links, sadly; I'll see if I can dig it up later.
On a somewhat related note, the most recent edition of the Audio Engineering Society's journal includes the interesting study"Audibility of a CD-Standard A/D/A Loop Inserted into High-Resolution Audio Playback", E. BRAD MEYER AND DAVID R. MORAN, J. Audio Eng. Soc., Vol. 55, No. 9, 2007. It pretty conclusively demonstrated that 16/44 (normal CD quality) and 24/96 (Super Audio CD/HDCD quality) raw audio are also essentially indistinguishable (using a long-term double-blind testing with hundreds of trials including college students, subscribers and editors of a well-known audiophile magazine, and professional mastering engineers). It notably included long-duration testing as well--not just the typical "listen for a few minutes to A, then a few minutes of B and try to distinguish". It was possible for some listeners to pick up differences under extreme conditions (scaling up the audio and jacking up the decibel levels), but not under normal "listening to it played normally on high-end audio equipment" conditions.
That's not to say that your SACD collection is worthless, but it's the care that goes into mastering products aimed at an audiophile market rather than the extra bits that might make it sound better (meaning that it's unlikely to be any better than that well-done Mobile Fidelity or whoever "audiophile" mastering of a standard CD, unless better mastering sources are found or something like that).
Have you ever used a PDA or graphing calculator that required a JTAG to un-brick after a failed update?
Yes, it's the norm for many of the the PDAs I've used, as well as many mp3 players and wireless routers.
In the early days of Linux-on-IPAQ development there were all kinds of people mailing their devices back in to Jim Gettys' handhelds.org group at Compaq for a reset if they got bricked (thankfully that was an alternative firmware actually supported by the vendor to some degree).
It's simply unacceptable in those markets.
No, it isn't.
Why should Apple get away with it in the iPhone?
Why should they be any different from everyone else?
since the software for the iPhones whole purpose is based around the AT&T network, yet it does mean they do not have to support it.
Hmmm. Even if the "whole purpose" is based around a service, the only way to avoid fulfilling the warranty terms when the product is used with something other than that service is to explicitly apply for an FTC waiver (which requires convincing the FTC that the item only works properly with the service and that the waiver is in the public interest). But you have to actually get that waiver _before_ using it, meaning it's got to be published in the Federal Register and an appropriate public comment time passed.
No warrantor of a consumer product may condition his written or implied warranty of such product on the consumer's using, in connection with such product, any article or service (other than article or service provided without charge under the terms of the warranty) which is identified by brand, trade, or corporate name; except that the prohibition of this subsection may be waived by the Commission if-- (1) the warrantor satisfies the Commission that the warranted product will function properly only if the article or service so identified is used in connection with the warranted product, and (2) the Commission finds that such a waiver is in the public interest. The Commission shall identify in the Federal Register, and permit public comment on, all applications for waiver of the prohibition of this subsection, and shall publish in the Federal Register its disposition of any such application, including the reasons therefor.
This seems to be the only part of the Act about 3rd-party services, though.
It looks to me like Apple may have a quite credible argument that the warranty isn't conditioned on using AT&T/Cingular; they'll happily fix phones that haven't been connected at all. The warranty is actually conditioned on not _modifying_ the product--which seems perfectly legal to me, much like those "no user servicable parts--warranty void if open" stickers.
But modifying, even forking GCC is practical You haven't looked at the gcc codebase, have you?
It may not be forkable for the average person off the street, but if actual compiler developers are unhappy enough with something then forking GCC is certainly practical and we have plenty of examples of that happening.
egcs forked gcc effectively enough that the fork displaced the original. Several bounds-checking gcc forks have been used in production systems. Apple and others have periodically forked (and sometimes re-merged).
Several years ago I tried making a linux to windows cross compiler and failed.
FWIW, if your issue was GCC politics that's pretty much what caused the egcs split (and re-merge eventually, with a new philosophy and maintenance crew in charge of GCC). So if you looked at things prior to the gcc 2.95 era, you were looking at a different set of maintainers (and politics/philosophy/etc) than what's there now.
I think I put a decent amount of effort into my attempts and I definitely knew how toproduce a standard linux hosted linux targeted instance of GCC that would produce working binaries. A few years later I installed watcom and while it did not support Linux, I could install already working binaries that allowed me to compile dos, windows, os/2 and netware binaries from my windows machine.
Now the reasons for this are largely political. GCC works just fine as a cross compiler, I'm sure today I could get it to work now that I have written a lot more code, compiled more tarballs, and generally know more than I did then. I was able to get a freebsd to windows cross compiler working just fine thanks to the ports collection. Watcom never got a ready for prime time linux compiler, but what they shipped to end users as "experimental" always was a windows hosted compiler targeting linux.
Now there is no technical reason that gcc or a third party can't make the cross compiling process simpler, but other than poor college students that like to experiment, anyone who needs a cross compiler either can do it themselves, can hire someone that can, or has to do a lot of hoop jumping.
Last time I did it it was pretty straightforward (as straightforward as cross-compilation can be), and the documentation included worked fine.
The problem is that to get a full cross-compiler setup isn't just a gcc problem; you need a libc (with headers), and a linker (binutils) as well, and libc is a particular pain.
I had no problems in the 2.96 era or thereabouts building a linux->windows cross-compiler using only the GCC-included instructions; I basically did: 1. Build binutils (linker), using "./configure --target=i386-mingw32 --prefix=/usr/local" or whatever target you're using 2. untar pre-built libc/headers in/usr/local 3. Build gcc using "./configure --target=i386-mingw32 --prefix=/usr/local --with-gnu-as=i386-redhat-linux".
The flags might be slightly wrong as that's from memory. Note that I didn't bother bootstrapping libc; if you want, that's also doable; see, e.g., http://www.libsdl.org/extras/win32/cross/README.txt if you want a simple hand-holding script to do it for you.
Just because you don't make good decisions while drunk doesn't mean you can't account for the consequences of your actions ahead of time (or for the consequences of the law).
When you know, while sober, that the penalties are severe, you plan ahead for them.
I sometimes like to go to the bar for a few drinks, and like most my judgement isn't quite as good when I've had a few. Consequently, I don't take my car to the bar; I taxi it there, and when I leave there's no possibility that I'm going to get behind the wheel drunk.
When I don't feel like doing that, I'll pick up some beer at the grocery store, drive home sober, and drink in the safety of my home.
It's called selling short. You borrow shares from a broker, sell them, and then later on the broker can come back at any time and you have to buy shares at the current price and return them to him.
So if you borrow 100 shares at $20 and sell them, you have $2000 in pocket. If the shares decline to $5, you can cover the short (buy 100 shares for $500 and return to the broker) and make $1500.
Unlike long positions, though, there's unlimited downside. If you hold $2000 in stock normally, the worst case is the company vanishes and you're out $2000. If you short Google at $10 a share for 200 shares when they IPO ($2000), and then they spike to $200 and your broker calls in the cover, you have to come up with $40000. You lose $38000 on what was originally $2000 worth of stock.
The lowest legal limit I know of is.08. That's enough to impair.
That's the DUI limit, but most states have a lower limit for OUI or DWI (e.g. in Washington, DC DWI is a $200-300 fine and up to 30 days in jail for.03-.05; penalties go up from there; in California, DWI starts at 0.04).
A lot of communication is things where nuance is not important but precision is; e.g. sending the link to a particular item in your issue tracker or a document that someone wants to read, the name of a function/method that someone needs, an email address, etc.
Transmitting that kind of thing verbally is inefficient and error prone.
Texting is also common for broadcast information that's mainly informative (sending a message to the 10 participants that the meeting is delayed 15 minutes since Frank is with a client, or is starting in 5 minutes, or has moved to the conference room out back)--the kind of stuff where it's pretty transient (hence no need for a formal memo/email) but where it's just inefficient to call everyone or stop by all their desks. Especially since an IM will more easily catch people who have stepped out to go to the bathroom or whatever than the phone will.
None of text/email/phone calls take the place of face-to-face conversation when high interactivity, debate, nuance, consensus-building, etc are required. Even the phone misses a lot of visual cues. But texting is way more efficient for a pretty large class of common communication than phone or email, and it most certainly helps eliminate ambiguity and guesswork when getting somewhat a precise link or method name quickly is required.
I'd say, in fact, that the vast majority of my work text messages are with people sitting in the same room as me; it's quite common for someone to verbally ask for the URL to something and someone else to text them the reply.
I use both. Really, IM is usually a lot better than email or phone for getting things done at work--it's still interactive once you both pick up, but it doesn't interrupt other work like the phone does.
For proposals and larger essays, email's the way to go, and occasionally you need the nuances of the phone. But most places I've worked have used IM extensively since about when AIM got popular--certainly by 1999, IM was more commonly used than email or phone in the offices I've been in. Indeed, by 2000 there were big corporate pollicies in place about what you could/couldn't talk about on IM, internal IM servers for the IT department to avoid going outside the intranet, etc.
Admittedlly, said offices are all in the tech field--but the medium itself is so valuable that I can't see its spread slowing.
Cetainly GP's X-Com is a glaring omission. I was going to add Starflight, which Star Control is a remake of, but neither is really a great game to replay now unlike X-Com--starflight has a bit more charm but it's one that I'd play more for nostalgia than as a great standalone game. X-Com has never been replicated, really.
Nethack really should be on the list, and pretty high (the tournament last month had the biggest turnout ever, so it's certainly still playable).
The Incredible Machine is replayable now and great fun, but I'm not familiar enough with everything on the list to say it should be in for sure.
Kind of like locksmithing tools, old credit cards, stethoscopes, Slim Jims, crowbars, and coat hangers are all criminal tools which are highly regulated?
E.g. in California:
Every person having upon him or her in his or her possession a picklock, crow, keybit, crowbar, screwdriver, vice grip pliers, water-pump pliers, slidehammer, slim jim, tension bar, lock pick gun, tubular lock pick, floor-safe door puller, master key, or other instrument or tool with intent feloniously to break or enter into any building, railroad car, aircraft, or vessel, trailer coach, or vehicle as defined in the Vehicle Code, or who shall knowingly make or alter, or shall attempt to make or alter, any key or other instrument above named so that the same will fit or open the lock of a building, railroad car, aircraft, or vessel, trailer coach, or vehicle as defined in the Vehicle Code, without being requested so to do by some person having the right to open the same, or who shall make, alter, or repair any instrument or thing, knowing or having reason to believe that it is intended to be used in committing a misdemeanor or felony, is guilty of misdemeanor.
Note that courts have ruled that for primary-purpose tools like lock picks, pick guns, slim jims, door pullers, etc possession without mitigating circumstances (e.g. licensed locksmith with lock picks, slim jim at a towing company, etc) constitutes proof of intent, while with non-primary-purpose tools (screwdriver, crowbar, vice grips, etc) intent requires separate proof.
The FSF has used the syscall interface as a guideline to determine whether something is a derived work or not. It is a guideline, not a hard rule though, and I suspect they would consider user-space ZFS for a derived work using a technical trick to avoid being linked into the kernel. I.e. infringing. However, since the FSF doesn't own the kernel, their opinion on the subject doesn't matter.
OTOH, some respected kernel developers (e.g. Alan Cox) certainly have explicitly said they believe binary kernel modules must be GPL and that things like nvidia's drivers are probably infringing. Not exactly the same thing but it's enough that I'd still call this a grey area until it's tested.
The point of the article is that there are a tiny fraction of developers actively writing C compared to those writing, say, Java (practically every enterprise app) or C++ (practically every desktop app). They are judging the "life" of a technology by the number of its practitioners.
The point of my post was that that isn't true, at least not for new projects. Java's flourishing, but 5-10 years ago C++ was the language of choice for a lot of new performance-critical apps. Today I'm not seeing it used nearly as much--places are mostly going with Java or even higher-level languages much of the time, and using small C extensions when needed. Even most of the desktop apps at the last 3 companies I've worked at have been written in Java, C#, or even occasionally Python and other higher-level languages. C++ seems to be going through the middle-life phase awfully early--it's still in high demand, and there's still active ongoing development of existing products (it's not just maintenance/bug fixing for legacy systems by any stretch), but it's really fallen out of favor for new products very quickly compared to what I would have guessed even 5 years ago.
Whereas C continues to fill the same spots it did 10 years ago, and has picked up a little ground as the native code language for many of the new higher-level languages out there. It shows far less signs of dying out than C++ at this point.
(On top of that, embedded is less of a "niche" field than desktop GUI app development--there are a _ton_ of embedded machines out there, and a ton of jobs developing for them.)
"hand-coding performance critical parts of large systems" are usually assembly.
No, they aren't. They're usually C. Occasionally they're asm. Sometimes they're awk or perl or python. It depends on what language the major product is written in.
The inner loop of Alta Vista is machine langauge (possibly google too, but I don't know). If you can squeeze one more cycle out, you aren't finished.
Yes, you are. If you have a program that's fast enough to do the job, wasting time optimizing it is just dumb. If it'll cost you less to get bigger hardware than the programmer time to optimize it, it'd be foolish to choose the more expensive option. Obviously for _some_ jobs, the faster they run the better--but you still have to weigh that against the cost of doing the optimization (rather than working on other useful programs). If you have a mass-market product that a lot of people are going to run, it's more likely that heavy optimization is worthwile.
But if you're at a point where squeezing more cycles out doesn't actually help you in any significant way, you're likely to be done even if the program _could_ go 10% (or 90%) faster.
I think they are wrong since C is still used on a lot of embedded systems where C++ is too heavy.
And plenty of the "vibrant replacements" for dying technologies are large, actively-developed C codebases (e.g. Python). If anything, based on what I've seen in the marketplace over the last 5 years I'd say C++ has been largely supplanted by higher level languages but C continues to be used a fair amount (especially in embedded systems as you note, but also for hand-coding performance critical parts of large systems that are mostly in other languages and for some other non-embedded work).
GHB isn't really a date-rape drug, it's one of the more popular club drugs these days. It's nasty stuff, but it's mostly used recreationally. I'd never heard it called a date-rape drug before, but it certainly could be used for such a purpose (as could alcohol or pretty much any sedative).
"Date-rape drug" usually connotes rohypnol, which is rarely used recreationally (and when it is, it's usually more to take the edge off your uppers or help out your heroin high than for anything "fun" it does itself). Though even that has rising recreational use, I guess for some people even ketamine leaves them too aware of their surroundings.
If money really won the championships, the Red Sox (second-highest spenders in all of baseball, they only spend something like 5% less than the Yankees) would have won more championships than they have.
1. The Red Sox spent $120 million last year--the Angels, White Sox, and Mets were all over $100 million (and 5 other teams were over $90 million). The Yankees spent $195 million. That's a hair bigger than a 5% difference (as in, the Yankees salary was 60% higher than the Red Sox--or the Red Sox salary was 40% lower than the Yankees--or half the teams in the league made less money than the difference between the Yanks and the Sox).
The Red Sox spend a lot, but it's pretty much in line with other high-spending teams. The Yankees eclipse everyone, and have a _massive_ monetary advantage.
2. In 2003, the Yankees, Mets, Braves, Dodgers, and Rangers all spent more than the Red Sox. Prior to 2000, the Red Sox hadn't even been in the top 5 in spending in years (since 1992--and even then they were still behind the Blue Jays in addition to the Yankees in their division). Through parts of the 1990s, they were in the bottom 1/2 of the league in spending.
Basically, they didn't spend _tons_ of money when they were losing. Using them as a "money doesn't win" example doesn't make sense--since opening up the pocketbooks, they've been quite successful (4 playoff berths and 1 WS in 5 years as the #2-spending team). Heck, they got started losing in 1919 when Babe Ruth was sold as a salary and cost-cutting measure to lower payroll.
the work of Voros McCracken strongly indicates that a pitcher only has individual predictability when it comes to preventing walks and home runs. When a ball is put in play, the individual ability of the pitcher has no effect, and whether a ball, once put in play, becomes a hit is determined about 50% by the fielding ability of the other players and about 50% by random chance.
Even at the time McCracken recognized that this simply wasn't true of certain classes of pitchers (closers, sinkerballers, knuckleballers). Since then, he's argued vehemently at people who misinterpreted his findings as "BABIP is complete luck, and not a pitching skill".
Generally since then, it's become apparent that BABIP (batting average on balls in play) _is_, in fact, a pitching skill--it's got a pretty high variance, but with a large enough sample size you can see that good pitchers actually do induce lower hit rates than bad ones (even controlling for defense).
Now, a lot of his core points remain--if you have a pitcher who suddenly has a terrible ERA one year, but he's maintained his K rate, BB rate, HR rate and just has a much worse BABIP you can be pretty sure it's not a real decline (just a bad year) and that he'll return to form the next year. But when Chien-Ming Wang maintains a lower than league average BABIP for years, you can't say it's going to regress to league average the next year, unfortunately.
Actually it doesn't matter where it's being used, in the CPU or elsewhere, every watt into your computer is going to end up heating your house.
Not _every_ watt. Most watts. Things like light and sound going out the window don't heat the house; they're pretty negligible power-wise, but I wouldn't be too surprised if a few watts from a wireless card heat the outside world rather than your house.
You're assuming that these non-competes are the result of negotiation between employee and employer. Often, they are not. They are presented to the employee with a demand that the employee sign or walk.
a) That's a negotiation. "If you'll sign X and do Y, I'll pay you $Z". "No thanks!" They're not forcing you to accept the contract. b) non-competes are unenforceable in many jurisdictions and must be very narrowly targeted in most jurisdictions c) I've _never_ had any problem getting reasonable changes made to employment contracts. I think people are scared to ask because they really want the job--just ask. They're not going to retract the offer because you made a reasonable request, the worst that happens is they say no. If it's a reasonable request, any decent company will probably try to accomodate it. Especially in an industry like software engineering where it's tough enough to find good employees already.
Slashdot Mirror
If you can keep up the pace, you can drive by car between any 2 points in the continental US in 72 hours: 60mph * 72h = 4320 miles. If you've got an emergency, you're better off driving, no matter how far
Hmm.
Miami, FL to Anchorage, AK is 5,000 miles by car. Even factoring in the 11-12 hour flight it's still faster to wait 3 days and fly (especially since you're not going to average 60 MPH on that drive).
But note that with a good indexer, "large numbers" should be pretty large. We have no problem handling about 500 requests/second for full-text paragraph-level searches of about 1 TB of data on a fairly modest machine. I can't remember the exact details, but it's something like a 1.8 GHz Pentium IV with 512 MB of RAM, and it's got plenty of room to grow (otherwise we'd at least add more RAM).
Failover for availability is certainly nice, but with a decent design it'd be surprising to need clustering for performance until you get well past the "what indexers are out there?" question-asking phase of your data mining career.
(The main thing we use clustering for is full regex searches, but the text indexer and smart caching can be used to make many common applications of those pretty fast as is).
If being an audiophile means having the sort of mindset to remotely accept that as plausible, suddenly I have much less respect for the audiophiles I know.
It doesn't. Most audiophiles are happy with 10 AWG $.57/ft cable with decent banana clips on it (the main concern being corrosion, but we're talking closer to $10 than $100 for a premium cable).
They'll spend decent money on speakers and a nice pair of Grados or Sennheisers, and they'll put curtains over that big glass door in the listening room, but they won't be buying $10,000 CD players with seperate transports and DACs, using green magic markers on the edges of the CDs, putting carbon fiber mats under their cables, buying $500 wooden knobs, or any of that crap.
These people who buy monster (or Pear anjou) cables are as much "audiophiles" as people who are into VTEC stickers, bolt-on hood "scoops", cut-off suspensions, clip-on wings, and so forth are gearheads.
It's not "elitist fuckery", it's a combination of good equipment, an original source recording of high quality, and perhaps better-than-average hearing.
Every actual study I've seen shows that except on certain "hard" classes of recordings it's wishful thinking or other psychology--with 99% of normal music (be it well-recorded classical, a capella voice, rock, whatever) the 256kbps VBR LAME settings Amazon uses haven't been distinguishable to anyone in any scientific study I'm aware of.
I've had this argument many times, and there are some recordings that reveal obvious flaws in even 320 kbps CBR mp3 to my ears with my headphones and amplifier
If you can do it regularly, then you should pretty easily be able to make thousands of dollars for a few hour's work by claiming any of the numerous prizes offered for people who can succesfully distinguish 256kbps VBR MP3 of a wide array of popular music from uncompressed originals in a double-blind A/B test.
Now, if you're just talking a handful of special-case horrible-for-mp3 recordings (like, say, the well-known Eig "LAME killer" sample) then that's another story; some people can certainly pick that one out at 320 kbps VBR.
You can easily start off using a free ABX program like PC ABX (Windows) or LinABX, or a more expensive hardware solution. Just see if you can actually ABX them at home and if so, you should be good to go claim some cash.
It's pretty fun to see what you can actually distinguish, too. I have a nice setup with a good pair of Grados; out of my library of 4000+ songs there are maybe 3-4 I've found so far that I can pick out a 192kbps Ogg from FLAC. Before doing such testing, I was "sure" I could pick out the difference between the original and the 320kbps encodings I usually make. Most people who come over to my place can't distinguish 96 kbps from uncompressed except on a handful of nasty test samples, but if you actually learn what the common artifacts are it gets a bit easier for some people.
More importantly the improved "quality" of 256 kb AAC over 256kb MP3 is largely hypothetical, few if any could tell the difference.
There are sites out there offering decent rewards (in the thousands of US$) to anyone able to tell the difference between 256kb MP3 and uncompressed audio in double-blind A/B tests (of course there are specifications on which version of LAME and options are used for the encoding). I just googled around and couldn't find the links, sadly; I'll see if I can dig it up later.
On a somewhat related note, the most recent edition of the Audio Engineering Society's journal includes the interesting study"Audibility of a CD-Standard A/D/A Loop Inserted into High-Resolution Audio Playback", E. BRAD MEYER AND DAVID R. MORAN, J. Audio Eng. Soc., Vol. 55, No. 9, 2007. It pretty conclusively demonstrated that 16/44 (normal CD quality) and 24/96 (Super Audio CD/HDCD quality) raw audio are also essentially indistinguishable (using a long-term double-blind testing with hundreds of trials including college students, subscribers and editors of a well-known audiophile magazine, and professional mastering engineers). It notably included long-duration testing as well--not just the typical "listen for a few minutes to A, then a few minutes of B and try to distinguish". It was possible for some listeners to pick up differences under extreme conditions (scaling up the audio and jacking up the decibel levels), but not under normal "listening to it played normally on high-end audio equipment" conditions.
That's not to say that your SACD collection is worthless, but it's the care that goes into mastering products aimed at an audiophile market rather than the extra bits that might make it sound better (meaning that it's unlikely to be any better than that well-done Mobile Fidelity or whoever "audiophile" mastering of a standard CD, unless better mastering sources are found or something like that).
Have you ever used a PDA or graphing calculator that required a JTAG to un-brick after a failed update?
Yes, it's the norm for many of the the PDAs I've used, as well as many mp3 players and wireless routers.
In the early days of Linux-on-IPAQ development there were all kinds of people mailing their devices back in to Jim Gettys' handhelds.org group at Compaq for a reset if they got bricked (thankfully that was an alternative firmware actually supported by the vendor to some degree).
It's simply unacceptable in those markets.
No, it isn't.
Why should Apple get away with it in the iPhone?
Why should they be any different from everyone else?
since the software for the iPhones whole purpose is based around the AT&T network, yet it does mean they do not have to support it.
Hmmm. Even if the "whole purpose" is based around a service, the only way to avoid fulfilling the warranty terms when the product is used with something other than that service is to explicitly apply for an FTC waiver (which requires convincing the FTC that the item only works properly with the service and that the waiver is in the public interest). But you have to actually get that waiver _before_ using it, meaning it's got to be published in the Federal Register and an appropriate public comment time passed.
No warrantor of a consumer product may condition his written or implied warranty of such product on the consumer's using, in connection with such product, any article or service (other than article or service provided without charge under the terms of the warranty) which is identified by brand, trade, or corporate name; except that the prohibition of this subsection may be waived by the Commission if--
(1) the warrantor satisfies the Commission that the warranted product will function properly only if the article or service so identified is used in connection with the warranted product, and
(2) the Commission finds that such a waiver is in the public interest.
The Commission shall identify in the Federal Register, and permit public comment on, all applications for waiver of the prohibition of this subsection, and shall publish in the Federal Register its disposition of any such application, including the reasons therefor.
This seems to be the only part of the Act about 3rd-party services, though.
It looks to me like Apple may have a quite credible argument that the warranty isn't conditioned on using AT&T/Cingular; they'll happily fix phones that haven't been connected at all. The warranty is actually conditioned on not _modifying_ the product--which seems perfectly legal to me, much like those "no user servicable parts--warranty void if open" stickers.
It may not be forkable for the average person off the street, but if actual compiler developers are unhappy enough with something then forking GCC is certainly practical and we have plenty of examples of that happening.
egcs forked gcc effectively enough that the fork displaced the original. Several bounds-checking gcc forks have been used in production systems. Apple and others have periodically forked (and sometimes re-merged).
FWIW, if your issue was GCC politics that's pretty much what caused the egcs split (and re-merge eventually, with a new philosophy and maintenance crew in charge of GCC). So if you looked at things prior to the gcc 2.95 era, you were looking at a different set of maintainers (and politics/philosophy/etc) than what's there now.
Last time I did it it was pretty straightforward (as straightforward as cross-compilation can be), and the documentation included worked fine.
The problem is that to get a full cross-compiler setup isn't just a gcc problem; you need a libc (with headers), and a linker (binutils) as well, and libc is a particular pain.
I had no problems in the 2.96 era or thereabouts building a linux->windows cross-compiler using only the GCC-included instructions; I basically did:
1. Build binutils (linker), using "./configure --target=i386-mingw32 --prefix=/usr/local" or whatever target you're using
2. untar pre-built libc/headers in
3. Build gcc using "./configure --target=i386-mingw32 --prefix=/usr/local --with-gnu-as=i386-redhat-linux".
The flags might be slightly wrong as that's from memory. Note that I didn't bother bootstrapping libc; if you want, that's also doable; see, e.g., http://www.libsdl.org/extras/win32/cross/README.txt if you want a simple hand-holding script to do it for you.
Just because you don't make good decisions while drunk doesn't mean you can't account for the consequences of your actions ahead of time (or for the consequences of the law).
When you know, while sober, that the penalties are severe, you plan ahead for them.
I sometimes like to go to the bar for a few drinks, and like most my judgement isn't quite as good when I've had a few. Consequently, I don't take my car to the bar; I taxi it there, and when I leave there's no possibility that I'm going to get behind the wheel drunk.
When I don't feel like doing that, I'll pick up some beer at the grocery store, drive home sober, and drink in the safety of my home.
It's called selling short. You borrow shares from a broker, sell them, and then later on the broker can come back at any time and you have to buy shares at the current price and return them to him.
So if you borrow 100 shares at $20 and sell them, you have $2000 in pocket. If the shares decline to $5, you can cover the short (buy 100 shares for $500 and return to the broker) and make $1500.
Unlike long positions, though, there's unlimited downside. If you hold $2000 in stock normally, the worst case is the company vanishes and you're out $2000. If you short Google at $10 a share for 200 shares when they IPO ($2000), and then they spike to $200 and your broker calls in the cover, you have to come up with $40000. You lose $38000 on what was originally $2000 worth of stock.
The lowest legal limit I know of is .08. That's enough to impair.
.03-.05; penalties go up from there; in California, DWI starts at 0.04).
That's the DUI limit, but most states have a lower limit for OUI or DWI (e.g. in Washington, DC DWI is a $200-300 fine and up to 30 days in jail for
A lot of communication is things where nuance is not important but precision is; e.g. sending the link to a particular item in your issue tracker or a document that someone wants to read, the name of a function/method that someone needs, an email address, etc.
Transmitting that kind of thing verbally is inefficient and error prone.
Texting is also common for broadcast information that's mainly informative (sending a message to the 10 participants that the meeting is delayed 15 minutes since Frank is with a client, or is starting in 5 minutes, or has moved to the conference room out back)--the kind of stuff where it's pretty transient (hence no need for a formal memo/email) but where it's just inefficient to call everyone or stop by all their desks. Especially since an IM will more easily catch people who have stepped out to go to the bathroom or whatever than the phone will.
None of text/email/phone calls take the place of face-to-face conversation when high interactivity, debate, nuance, consensus-building, etc are required. Even the phone misses a lot of visual cues. But texting is way more efficient for a pretty large class of common communication than phone or email, and it most certainly helps eliminate ambiguity and guesswork when getting somewhat a precise link or method name quickly is required.
I'd say, in fact, that the vast majority of my work text messages are with people sitting in the same room as me; it's quite common for someone to verbally ask for the URL to something and someone else to text them the reply.
I use both. Really, IM is usually a lot better than email or phone for getting things done at work--it's still interactive once you both pick up, but it doesn't interrupt other work like the phone does.
For proposals and larger essays, email's the way to go, and occasionally you need the nuances of the phone. But most places I've worked have used IM extensively since about when AIM got popular--certainly by 1999, IM was more commonly used than email or phone in the offices I've been in. Indeed, by 2000 there were big corporate pollicies in place about what you could/couldn't talk about on IM, internal IM servers for the IT department to avoid going outside the intranet, etc.
Admittedlly, said offices are all in the tech field--but the medium itself is so valuable that I can't see its spread slowing.
Cetainly GP's X-Com is a glaring omission. I was going to add Starflight, which Star Control is a remake of, but neither is really a great game to replay now unlike X-Com--starflight has a bit more charm but it's one that I'd play more for nostalgia than as a great standalone game. X-Com has never been replicated, really.
Nethack really should be on the list, and pretty high (the tournament last month had the biggest turnout ever, so it's certainly still playable).
The Incredible Machine is replayable now and great fun, but I'm not familiar enough with everything on the list to say it should be in for sure.
E.g. in California:
Note that courts have ruled that for primary-purpose tools like lock picks, pick guns, slim jims, door pullers, etc possession without mitigating circumstances (e.g. licensed locksmith with lock picks, slim jim at a towing company, etc) constitutes proof of intent, while with non-primary-purpose tools (screwdriver, crowbar, vice grips, etc) intent requires separate proof.
The FSF has used the syscall interface as a guideline to determine whether something is a derived work or not. It is a guideline, not a hard rule though, and I suspect they would consider user-space ZFS for a derived work using a technical trick to avoid being linked into the kernel. I.e. infringing. However, since the FSF doesn't own the kernel, their opinion on the subject doesn't matter.
OTOH, some respected kernel developers (e.g. Alan Cox) certainly have explicitly said they believe binary kernel modules must be GPL and that things like nvidia's drivers are probably infringing. Not exactly the same thing but it's enough that I'd still call this a grey area until it's tested.
The point of the article is that there are a tiny fraction of developers actively writing C compared to those writing, say, Java (practically every enterprise app) or C++ (practically every desktop app). They are judging the "life" of a technology by the number of its practitioners.
The point of my post was that that isn't true, at least not for new projects. Java's flourishing, but 5-10 years ago C++ was the language of choice for a lot of new performance-critical apps. Today I'm not seeing it used nearly as much--places are mostly going with Java or even higher-level languages much of the time, and using small C extensions when needed. Even most of the desktop apps at the last 3 companies I've worked at have been written in Java, C#, or even occasionally Python and other higher-level languages. C++ seems to be going through the middle-life phase awfully early--it's still in high demand, and there's still active ongoing development of existing products (it's not just maintenance/bug fixing for legacy systems by any stretch), but it's really fallen out of favor for new products very quickly compared to what I would have guessed even 5 years ago.
Whereas C continues to fill the same spots it did 10 years ago, and has picked up a little ground as the native code language for many of the new higher-level languages out there. It shows far less signs of dying out than C++ at this point.
(On top of that, embedded is less of a "niche" field than desktop GUI app development--there are a _ton_ of embedded machines out there, and a ton of jobs developing for them.)
"hand-coding performance critical parts of large systems" are usually assembly.
No, they aren't. They're usually C. Occasionally they're asm. Sometimes they're awk or perl or python. It depends on what language the major product is written in.
The inner loop of Alta Vista is machine langauge (possibly google too, but I don't know). If you can squeeze one more cycle out, you aren't finished.
Yes, you are. If you have a program that's fast enough to do the job, wasting time optimizing it is just dumb. If it'll cost you less to get bigger hardware than the programmer time to optimize it, it'd be foolish to choose the more expensive option. Obviously for _some_ jobs, the faster they run the better--but you still have to weigh that against the cost of doing the optimization (rather than working on other useful programs). If you have a mass-market product that a lot of people are going to run, it's more likely that heavy optimization is worthwile.
But if you're at a point where squeezing more cycles out doesn't actually help you in any significant way, you're likely to be done even if the program _could_ go 10% (or 90%) faster.
I think they are wrong since C is still used on a lot of embedded systems where C++ is too heavy.
And plenty of the "vibrant replacements" for dying technologies are large, actively-developed C codebases (e.g. Python). If anything, based on what I've seen in the marketplace over the last 5 years I'd say C++ has been largely supplanted by higher level languages but C continues to be used a fair amount (especially in embedded systems as you note, but also for hand-coding performance critical parts of large systems that are mostly in other languages and for some other non-embedded work).
GHB isn't really a date-rape drug, it's one of the more popular club drugs these days. It's nasty stuff, but it's mostly used recreationally. I'd never heard it called a date-rape drug before, but it certainly could be used for such a purpose (as could alcohol or pretty much any sedative).
"Date-rape drug" usually connotes rohypnol, which is rarely used recreationally (and when it is, it's usually more to take the edge off your uppers or help out your heroin high than for anything "fun" it does itself). Though even that has rising recreational use, I guess for some people even ketamine leaves them too aware of their surroundings.
If money really won the championships, the Red Sox (second-highest spenders in all of baseball, they only spend something like 5% less than the Yankees) would have won more championships than they have.
1. The Red Sox spent $120 million last year--the Angels, White Sox, and Mets were all over $100 million (and 5 other teams were over $90 million). The Yankees spent $195 million. That's a hair bigger than a 5% difference (as in, the Yankees salary was 60% higher than the Red Sox--or the Red Sox salary was 40% lower than the Yankees--or half the teams in the league made less money than the difference between the Yanks and the Sox).
The Red Sox spend a lot, but it's pretty much in line with other high-spending teams. The Yankees eclipse everyone, and have a _massive_ monetary advantage.
2. In 2003, the Yankees, Mets, Braves, Dodgers, and Rangers all spent more than the Red Sox. Prior to 2000, the Red Sox hadn't even been in the top 5 in spending in years (since 1992--and even then they were still behind the Blue Jays in addition to the Yankees in their division). Through parts of the 1990s, they were in the bottom 1/2 of the league in spending.
Basically, they didn't spend _tons_ of money when they were losing. Using them as a "money doesn't win" example doesn't make sense--since opening up the pocketbooks, they've been quite successful (4 playoff berths and 1 WS in 5 years as the #2-spending team). Heck, they got started losing in 1919 when Babe Ruth was sold as a salary and cost-cutting measure to lower payroll.
the work of Voros McCracken strongly indicates that a pitcher only has individual predictability when it comes to preventing walks and home runs. When a ball is put in play, the individual ability of the pitcher has no effect, and whether a ball, once put in play, becomes a hit is determined about 50% by the fielding ability of the other players and about 50% by random chance.
Even at the time McCracken recognized that this simply wasn't true of certain classes of pitchers (closers, sinkerballers, knuckleballers). Since then, he's argued vehemently at people who misinterpreted his findings as "BABIP is complete luck, and not a pitching skill".
Generally since then, it's become apparent that BABIP (batting average on balls in play) _is_, in fact, a pitching skill--it's got a pretty high variance, but with a large enough sample size you can see that good pitchers actually do induce lower hit rates than bad ones (even controlling for defense).
Now, a lot of his core points remain--if you have a pitcher who suddenly has a terrible ERA one year, but he's maintained his K rate, BB rate, HR rate and just has a much worse BABIP you can be pretty sure it's not a real decline (just a bad year) and that he'll return to form the next year. But when Chien-Ming Wang maintains a lower than league average BABIP for years, you can't say it's going to regress to league average the next year, unfortunately.
Actually it doesn't matter where it's being used, in the CPU or elsewhere, every watt into your computer is going to end up heating your house.
Not _every_ watt. Most watts. Things like light and sound going out the window don't heat the house; they're pretty negligible power-wise, but I wouldn't be too surprised if a few watts from a wireless card heat the outside world rather than your house.
You're assuming that these non-competes are the result of negotiation between employee and employer. Often, they are not. They are presented to the employee with a demand that the employee sign or walk.
a) That's a negotiation. "If you'll sign X and do Y, I'll pay you $Z". "No thanks!" They're not forcing you to accept the contract.
b) non-competes are unenforceable in many jurisdictions and must be very narrowly targeted in most jurisdictions
c) I've _never_ had any problem getting reasonable changes made to employment contracts. I think people are scared to ask because they really want the job--just ask. They're not going to retract the offer because you made a reasonable request, the worst that happens is they say no. If it's a reasonable request, any decent company will probably try to accomodate it. Especially in an industry like software engineering where it's tough enough to find good employees already.