Just like vinyl sounds better to an audiophile's ears than a CD, videotape just looks better to a videophiles eyes than a DVD.
Speaking as a videophile, I have to disagree.
The analog encoding on VHS loses high-frequency information way too fast. (See this comparison for the sillyscope pics. It's comparing SVHS to VHS, but you can see how they all lose HF info.) Signal bleed and stretch kick in a week after you buy the tape. Moire (colors appearing in a black and white pattern) and susceptibility to poor combing (losing edges around 3.5 MHz) is inescapable, because the chroma signal is still overlaid on the intensity signal. (This last sentence applies if you hook up the DVD player with a composite cable, but I'm concentrating on VHS format problems, not connection follies.)
I know people who prefer laserdisc, which is an analog format, to DVD. It suffers from some of the problems as VHS (such as moire), but it does have a much higher bandwidth than VHS, meaning better resolution-- a sharper picture and clearer detail.
These laserdisc holdouts are a dwindling breed, though. The DVD revolution has taken hold.
So videophiles don't prefer VHS. What's PateraSilk's deal? I'm guessing he saw bad examples: poor transfers, possibly, or a bad (or misconfigured) player adding stairsteps when it downconverted a 16:9 tape. (See my other post in this article.) But I can't imagine anybody prefering VHS to DVD in general.
Another common problem I see is watching an anamorphic-mode DVD on a non-anamorphic-aware TV. Most consumer DVD players do a lousy job of antialiasing, so you get hideous stairsteps. The best example I know of is the opening credit sequence on the "Spider-Man" DVD. Looks great on an anamorphic-capable TV. (I thought about this when I saw it in the theater. Geek life strikes again.) Lots of stairsteps on a non-anamorphic TV, or if you have your DVD set to "4:3 Letterbox" when you have a 16:9 (anamorphic) capable TV. (Remember, not all 16:9-capable TVs have a 16:9 glass face!)
This type of artifacting looks hideous, and could turn somebody off of DVDs if they didn't know what was going on.
Hmm. I'll be damned. It does in fact say third party in section 3b. Thanks!
Note that the "third party" in section 3b is required only so that section 3c is acceptable. Of course, it's almost always easiest to apply section 3a instead.
Ugh. I couldn't stand it. I couldn't believe that Rawlings would have signed off on it, had she actually played the game.
The camera controls were terrible, and a number of areas were only difficult because of that-- you couldn't line up right for a jump! The levels themselves had nothing to do with Harry Potter, and could have been prepared for any game beforehand; I suspect they were.
The overland area was okay, but walking into a dozen identical classrooms and checking a dozen identical desks each is not my idea of a goodtime.
The graphics were terrible. Characters made as if the game designers were each paying a knut per poly used per frame. Even the cutscenes were rendered realtime with the same crap models. That's fine when your graphics are good, but when they suck, render them with good models ahead of time and store it as a movie. Or just use better models; the GC supports it! Look at the graphics on other adventure games like Zelda or Starfox Adventures, and then at Harry Potter, and wonder what happened.
The only redeeming aspect of the game is that flying around campus tagging rings can be kinda relaxing. But even there, the campus map is uninspired, hardly the jaw-dropping awe-inducing wonder that I think of when I think Hogwart's.
Didn't follow the storyline to a T? It had almost nothing to do with the story! It was amazingly generic, and had the final level that was reminescient of the book (but different enough that if you only saw the movie, you might not recognize it) and a few cutscenes thrown in at the end of production to remind the player that there is a book by the same name.
The levels were astoundingly dull. I'd play it in Picture-in-Picture while watching TV just to see if it ever got better, but it couldn't hold my attention enough to play it on its own. Walk a bit, cast expelliramus, walk a bit, cast expelliramus, sidle along a wall, cast expelliramus, walk a bit. Never encounter anything interesting or exciting.
It doesn't take 18 years of playing games to make the game too easy. Who were they targeting? This game would be too easy for almost anybody aged seven to eighteen years. Remember, kids these days-- particularly the ones who own GameCubes-- are good at video games. They have fast reflexes and precision hand-eye coordination. (You don't need problem-solving skills in this game.) The only thing that the modern child is lacking is the patience needed to search a gross schooldesks for an item. But that doesn't make it challenging; that makes it dull.
There was absolutely nothing about this game that did not make me feel it was a big waste of money. I recieved it as a gift (by somebody who doesn't read/., of course). Now, every time I see it sitting with my other GC games, I feel bad for the giver, who wasted good money-- $50 was the going price, IIRC-- to buy me this crappy game. She thought she was getting me something I would enjoy, that would bring me hours of fun. Boy, she got ripped.
Same as anybody else. Some lawyers are good people, some are not.
Re:Money crunches create platform dependencies
on
Analysis: x86 Vs PPC
·
· Score: 1
Is it acceptable to take a whole minute to manually serialize or de-serialize a complicated preinitialized data structure byte-by-byte, especially if the data structure is too large to fit into RAM?
Can it be created as part of the installation? Or deserialized then? I'm not saying it's evil to ever read architecture-dependant files; just be aware of the issue, and take appropriate steps to adapt.
Not in some of the real-time simulation apps I write.
If what you're doing is truly real-time (a widely misunderstood concept), then you need a real-time OS and architecture. Truly real-time apps are rarely portable, but they rarely need to be.
Maybe you don't need real-time, but actually need it to be very fast. So deserialize your data ahead of time. If you're having a network conversation, then maybe you can agree on a structure that meets both ends' data alignment requirements at the beginning of the session. Then all you have to do is swap bytes, and that doesn't take long. (Deserialization doesn't take long either, if you are writing a serialization protocol that meets your needs.)
Get creative.
Can database tables be moved from one architecture to another without dumping to text?
Depends on the database system, but rarely. Did you see where I said, "This only applies if your external data has a chance of moving across architectures"? Database systems usually have special procedures to move databases.
In ANSI C (C89/C90, not C99 which few compilers support), how do I get a 32-bit integer type that won't be 16-bit or 64-bit?
"A bare C program is about as portable as Chuck Yeager on foot." -Programming Perl
You're almost certain to use autoconf, imake, or something similar if you're releasing a program. Use it.
So how do I check a program to make sure that I have not used such an assumption, without spending hours reading over the source code line-by-line several times?
The best bet is usually to try to be aware of the issues. How do you check that you didn't have a race condition, or a buffer overflow possibility? You make yourself aware of the problems, so they're in mind while you're programming.
There's nothing magical about it. It's something you need to be aware of. That's why there's a difference between a skilled, professional, knowledgable programmer and somebody who just finished "Perl for Dummies".
Yes, but then how do I test graphical code?
Beats me. Graphics aren't my area; the most graphically-intensive thing I've ever done was a stupid weekend hack. At work, I only use graphics for simple things like editing type lattices. This is stuff that works fine on remote X11, so you can test it that way. If your sims are graphically-intensive, then I'm not sure what to tell you. Maybe somebody who does more graphics work can say something.
Unlike you, I have not been successful in finding friends that have computers other than PCs and game consoles.
Unlike you, I have not been successful in finding a job in my field (programming) in the area where my family lives (Fort Wayne, Indiana).
Okay. Some of my tips may not apply to you. I'm an insensitive clod, I guess. Personally, I left my hometown of San Angelo, Texas and came to the Silicon Valley to find work.
But having grown up in West Texas, I know, it's tough to learn to code well if you're isolated. I got a lot better when I started volunteering to work on GNU projects. (This was long before free software became well-known.) Maybe you should get involved in some projects with other people.
Look, I'm not saying that you're a terrible programmer if you ever write anything that isn't portable. I'm saying that programmers should be aware that there are other platforms than their own. Try to be aware of when you're making an assumption about the architecture. If you can make it portable without breaking your program, then good. If not, document it-- and maybe add something like '#ifndef i386 / #error "See ARCHITECTURE NOTES in the docs" / #endif'.
Applications will only break if they relied on specific random ordering ACCROSS EXECUTIONS. E.g., if you dumped the contents of a hash into a file on two runs, and then compared, you may now get different ordering on identical data, whereas before you would (coincidentally) get the same random ordering and there would be no difference between the files. You probably shouldn't have been relying on this to begin with.
Actually, I was. I have one test suite for a system, in which I make a "reference run" that gets dumped to a file. Then I make changes, or adjust timings, and so forth, then repeat the reference run to make sure there's no regressions. I can't hardcode many of the results in the test suite, since they depend on a database that is changing daily (or more frequently).
Presuming the resume (well, mine is a CV) is going to reputable employment agencies,
People misunderstand. Things get screwed up. And if you post on dice.com or something, all bets are off. I've seen people with the best of intentions get into trouble by putting out a resume before they were ready to.
Yup. There's a lot of badly written apps out there.
The PPC can switch between endian states.
Yes, but the badly written apps are not going to be doing the work to switch endianness modes.
Re:Money crunches create platform dependencies
on
Analysis: x86 Vs PPC
·
· Score: 1
C is the biggest problem child. There's a whole lot of implications, but here's the most common ones:
Endianness. If you're reading and writing ints (or anything longer than a char) from a file or network socket, use the ntohl and family to make sure the external format is always consistent. (This only applies if your external data has a chance of moving across architectures, so temp files are fine to ignore this on, but save files aren't.)
Struct padding. The padding requirements of different architectures varies. If you are storing or sending structs, do so element by element rather than a struct at a time.
Pointers. Don't assume that all pointers are equivilent, so don't stuff something as a char* and read it as an int*, unless you do appropriate casts.
Pointer size. Don't store pointers in ints or vice versa. The most common problem with this is forgetting to prototype your functions.
Chars. They may be signed on some architectures, and unsigned on others. Always use 'signed char' or 'unsigned char' if you care, or are using an external file or network socket.
Read/write alignment. Don't expect to be able to store ints, pointers, etc. in arbitrary places. (This is rarely a problem.)
Size of ints. Make no assumptions.
Most of these are implicitly used without the programmer realizing it, for example, by forgetting to #include prototypes, or by storing a long in an int variable.
It's also frequently easy to get access to different machines. Check with your friends (hobbyists often have old Alphas or Suns, and PPCs are becoming more common), check at work, use a build farm like Sourceforge's, etc.
As the article observes, Linux (and open-source software in general) is not locked into the x86 architecture like Windows is.
While true in theory, a decent number of Linux apps assume they're on an x86. The big killer between x86 and PPC, I think, is byte order, but pointer sizes and what not may come into play as we approach the 64-bit era.
You may want to read up on scheduler algorithms... the traditional Unix scheduler is similar to this. Substitute "nice value" for "seniority", and adjust the PRI based on pages received rather than cycles consumed, and volunteers are essentially using yield, and you've got a pretty decent starting point.
My main concern is detecting RFID. My understanding is that there is talk about self-destructing RFID chips, so once I pay for my purchase, I'm no longer being tracked.
If Wal-Mart implements self-destructing RFID tags, and Target doesn't, where am I shopping? But how can I know? The clerk certainly can't tell me, and managers are often misinformed about technology issues. (He may think I'm a tinfoil hat guy when I ask.)
So is it feasible for consumers to purchase RFID scanners? Can I tell if my own (or my friends') stuff is RFID tagged? (Can I use this to find if my associates are wearing women's underwear??? Step 3: Profit!)
Maybe local users' groups can pool together to get group-owned RFID scanners, like we used to do with re-inkers in the dot matrix days.
Here's how it differs. The program is doing something that is substantially different than what the user believes it is doing. If you go up to somebody who has the Gator forms handler installed, and say "What does that program do?" they'll say "It fills in forms." If you say, "Do you have any programs installed that alter website advertising?", they'll say "No."
I don't think that users should be expected to understand every aspect of a program's operation. But I think that the fact that Gator does something substantially different than what the user believes, and that this subversion is unrelated to and unnecessary for its primary task, then it's different.
It can be argued that the EULA gives them permission to do stuff. But there's good legal arguments (from my understanding, but IANAL) that EULAs are unenforcable (based on a general rule about non-negotiable contracts). So here's a question. Does the act of installing a program give it license to do whatever it wants, or is it only allowed to do stuff that is part of its advertised purpose?
Personally, I think that it should not. Did the judge make the right call? I don't know enough about law to answer that. But if the judge ruled in accordance with the law, then perhaps the law should be changed.
I didn't see anything in the article about what versions of closed-source codebases they used for comparison. But I'd hypothesize that it's code that they've been contracted to analyze. That means it's probably development code in that event, too.
We can't gritch about them using Apache 2.1-dev unless we have reason to believe they didn't compare againt dev versions. We can gritch about not having this information.
Do you have any references for this event? I'd like to find out more. (References to the halting problem by itself are not necessary; just this event.)
dilbert tanked 'cuz . ..(dramatic pause)
it wasn't funny!
Personally, I didn't like it when I saw it during its run. After a time I figured out why: Loud Howard. For some reason, they decided to make this one-off gag (that wasn't very funny to begin with) into what was almost a main character. I'd wince every time he spoke on the main show. (This could have to do with my roommate, who suffered hearing loss from working on F-4s and turned the TV way up.) I wouldn't enjoy the show.
Now they're showing it on Comedy Central, and I'm convinced that they're compressing Loud Howard's voice. I still don't like the character, but my mood doesn't drop a few percent every time he drops. Now I do enjoy the show.
Or maybe it's because I've worked at some more big corps now and can better empathize.
had he talked about the whole system, I'm quite sure he'd have used GNU/*BSD.
I doubt it. BSD has its own history as an OS, apart from GNU. FreeBSD does borrow some GNU utilities: bc/dc, binutils, gcc, cpio, cvs, dialog, diff, gperf, grep, groff, gzip, man, patch, send-pr, sort, tar, texinfo, and libreadline. We have some GNU libs (such as libiberty and libregex) to support the GNU utils, although we have similar replacements for the rest of the OS. Many of these utilities were adopted later in *BSD's life. For example, gcc replaced pcc.
Most of the rest of the OS is ours. I don't have room to give a comprehensive list, but some key players include fileutils, shellutils, ssh, libc (and most other libs), netutils, vi, init, fsutils, sendmail, and named.
It would have been nice for you to mention that you're using a Mac, instead of obtusely implying it (8600, BBEdit Lite).
The section of OSX that copying a file involves is not BSD-related, as I understand it. It's Mach. (People who know more about OSX than I do, feel free to pipe up.) The kernel of OSX is not very BSD-based, and most of what you're talking about (HDD access, scheduling) takes place in the kernel. (To be fair, the scheduler that FreeBSD uses was adapted from Mach.)
The 8600 (which was discontinued over a half decade ago, by the way) is not even compatible with OSX. The minimum requirement for OSX is the Beige Power Mac G3. (See Apple's requirements page.)
So, I'm guessing you put in a G3 daughterboard. (Find out about the 8600 and available daughterboards at lowendmac.com.)
But OSX doesn't support processor upgrade cards. (First paragraph of the requirements page.) Maybe you didn't put in an upgrade card, and are using the mach_kernel for the 604 from the Darwin project like this guy did. Either way, you're still not using a supported system.
So, you're using unsupported hardware, and a BSD-related OS in an operation that's not related to the BSD bits, and using this to say that BSD sucks. Hmmm.
I'm surprised an 8600 w/ daughterboard (which one, by the way? The 233MHz with 512k of cache?) works at all with OSX. As for why it's slow for you, I can only hypothesize, since I'm not a Mac guy. (That's right, anybody can find this stuff out with a quick google search or two!) The G3 upgrade card is going to need an L2 cache enabler. Do you have one installed? Okay, how about this idea. I'm guessing that your old, discontinued, unsupported hardware uses a bus controller (or other critical chip) that is not being programmed optimally by OSX. Why? Because the programmer writing that code knew that the chip wasn't going to be supported!
My advice is to stick to using 9.1 on your 8600. And don't generalize about BSD from your situation; it's an extreme.
Perhaps they can use these to find the upper echelon, see how they fit the high end of the standard curve, and then judge the mean that way. I'm assuming it'll be a dutch auction, so they can generate a histogram.
But I slept through a lot of my statistics class, so I don't know if this would work or not. But I did learn that statisticians have some powerful techniques at their disposal.
I expect it would. In slow-and-go traffic, you get worse milage than if you can breeze right on along.
To take this to its logical conclusion: if retasking the HOV lane to a general-purpose lane would significantly reduce slow-and-go traffic, it would not only improve peoples' commute times, but may also lower emissions pollution.
I say "may", because if a lot of people use HOV in your area, and would switch to single-driver cars if there were no HOV lane, then the increase in the number of cars may outweigh the benefits of reduced emissions from all cars. But I doubt that's the case, at least not where I've driven with HOV lanes (Dallas and Silicon Valley).
Slashdot Mirror
Just like vinyl sounds better to an audiophile's ears than a CD, videotape just looks better to a videophiles eyes than a DVD.
Speaking as a videophile, I have to disagree.
The analog encoding on VHS loses high-frequency information way too fast. (See this comparison for the sillyscope pics. It's comparing SVHS to VHS, but you can see how they all lose HF info.) Signal bleed and stretch kick in a week after you buy the tape. Moire (colors appearing in a black and white pattern) and susceptibility to poor combing (losing edges around 3.5 MHz) is inescapable, because the chroma signal is still overlaid on the intensity signal. (This last sentence applies if you hook up the DVD player with a composite cable, but I'm concentrating on VHS format problems, not connection follies.)
I know people who prefer laserdisc, which is an analog format, to DVD. It suffers from some of the problems as VHS (such as moire), but it does have a much higher bandwidth than VHS, meaning better resolution-- a sharper picture and clearer detail.
These laserdisc holdouts are a dwindling breed, though. The DVD revolution has taken hold.
So videophiles don't prefer VHS. What's PateraSilk's deal? I'm guessing he saw bad examples: poor transfers, possibly, or a bad (or misconfigured) player adding stairsteps when it downconverted a 16:9 tape. (See my other post in this article.) But I can't imagine anybody prefering VHS to DVD in general.
Another common problem I see is watching an anamorphic-mode DVD on a non-anamorphic-aware TV. Most consumer DVD players do a lousy job of antialiasing, so you get hideous stairsteps. The best example I know of is the opening credit sequence on the "Spider-Man" DVD. Looks great on an anamorphic-capable TV. (I thought about this when I saw it in the theater. Geek life strikes again.) Lots of stairsteps on a non-anamorphic TV, or if you have your DVD set to "4:3 Letterbox" when you have a 16:9 (anamorphic) capable TV. (Remember, not all 16:9-capable TVs have a 16:9 glass face!)
This type of artifacting looks hideous, and could turn somebody off of DVDs if they didn't know what was going on.
Hmm. I'll be damned. It does in fact say third party in section 3b. Thanks!
Note that the "third party" in section 3b is required only so that section 3c is acceptable. Of course, it's almost always easiest to apply section 3a instead.
Ugh. I couldn't stand it. I couldn't believe that Rawlings would have signed off on it, had she actually played the game.
The camera controls were terrible, and a number of areas were only difficult because of that-- you couldn't line up right for a jump! The levels themselves had nothing to do with Harry Potter, and could have been prepared for any game beforehand; I suspect they were.
The overland area was okay, but walking into a dozen identical classrooms and checking a dozen identical desks each is not my idea of a goodtime.
The graphics were terrible. Characters made as if the game designers were each paying a knut per poly used per frame. Even the cutscenes were rendered realtime with the same crap models. That's fine when your graphics are good, but when they suck, render them with good models ahead of time and store it as a movie. Or just use better models; the GC supports it! Look at the graphics on other adventure games like Zelda or Starfox Adventures, and then at Harry Potter, and wonder what happened.
The only redeeming aspect of the game is that flying around campus tagging rings can be kinda relaxing. But even there, the campus map is uninspired, hardly the jaw-dropping awe-inducing wonder that I think of when I think Hogwart's.
Didn't follow the storyline to a T? It had almost nothing to do with the story! It was amazingly generic, and had the final level that was reminescient of the book (but different enough that if you only saw the movie, you might not recognize it) and a few cutscenes thrown in at the end of production to remind the player that there is a book by the same name.
The levels were astoundingly dull. I'd play it in Picture-in-Picture while watching TV just to see if it ever got better, but it couldn't hold my attention enough to play it on its own. Walk a bit, cast expelliramus, walk a bit, cast expelliramus, sidle along a wall, cast expelliramus, walk a bit. Never encounter anything interesting or exciting.
It doesn't take 18 years of playing games to make the game too easy. Who were they targeting? This game would be too easy for almost anybody aged seven to eighteen years. Remember, kids these days-- particularly the ones who own GameCubes-- are good at video games. They have fast reflexes and precision hand-eye coordination. (You don't need problem-solving skills in this game.) The only thing that the modern child is lacking is the patience needed to search a gross schooldesks for an item. But that doesn't make it challenging; that makes it dull.
There was absolutely nothing about this game that did not make me feel it was a big waste of money. I recieved it as a gift (by somebody who doesn't read /., of course). Now, every time I see it sitting with my other GC games, I feel bad for the giver, who wasted good money-- $50 was the going price, IIRC-- to buy me this crappy game. She thought she was getting me something I would enjoy, that would bring me hours of fun. Boy, she got ripped.
Same as anybody else. Some lawyers are good people, some are not.
Is it acceptable to take a whole minute to manually serialize or de-serialize a complicated preinitialized data structure byte-by-byte, especially if the data structure is too large to fit into RAM?
Can it be created as part of the installation? Or deserialized then? I'm not saying it's evil to ever read architecture-dependant files; just be aware of the issue, and take appropriate steps to adapt.
Not in some of the real-time simulation apps I write.
If what you're doing is truly real-time (a widely misunderstood concept), then you need a real-time OS and architecture. Truly real-time apps are rarely portable, but they rarely need to be.
Maybe you don't need real-time, but actually need it to be very fast. So deserialize your data ahead of time. If you're having a network conversation, then maybe you can agree on a structure that meets both ends' data alignment requirements at the beginning of the session. Then all you have to do is swap bytes, and that doesn't take long. (Deserialization doesn't take long either, if you are writing a serialization protocol that meets your needs.)
Get creative.
Can database tables be moved from one architecture to another without dumping to text?
Depends on the database system, but rarely. Did you see where I said, "This only applies if your external data has a chance of moving across architectures"? Database systems usually have special procedures to move databases.
In ANSI C (C89/C90, not C99 which few compilers support), how do I get a 32-bit integer type that won't be 16-bit or 64-bit?
"A bare C program is about as portable as Chuck Yeager on foot." -Programming Perl
You're almost certain to use autoconf, imake, or something similar if you're releasing a program. Use it.
So how do I check a program to make sure that I have not used such an assumption, without spending hours reading over the source code line-by-line several times?
The best bet is usually to try to be aware of the issues. How do you check that you didn't have a race condition, or a buffer overflow possibility? You make yourself aware of the problems, so they're in mind while you're programming.
There's nothing magical about it. It's something you need to be aware of. That's why there's a difference between a skilled, professional, knowledgable programmer and somebody who just finished "Perl for Dummies".
Yes, but then how do I test graphical code?
Beats me. Graphics aren't my area; the most graphically-intensive thing I've ever done was a stupid weekend hack. At work, I only use graphics for simple things like editing type lattices. This is stuff that works fine on remote X11, so you can test it that way. If your sims are graphically-intensive, then I'm not sure what to tell you. Maybe somebody who does more graphics work can say something.
Unlike you, I have not been successful in finding friends that have computers other than PCs and game consoles.
Unlike you, I have not been successful in finding a job in my field (programming) in the area where my family lives (Fort Wayne, Indiana).
Okay. Some of my tips may not apply to you. I'm an insensitive clod, I guess. Personally, I left my hometown of San Angelo, Texas and came to the Silicon Valley to find work.
But having grown up in West Texas, I know, it's tough to learn to code well if you're isolated. I got a lot better when I started volunteering to work on GNU projects. (This was long before free software became well-known.) Maybe you should get involved in some projects with other people.
Look, I'm not saying that you're a terrible programmer if you ever write anything that isn't portable. I'm saying that programmers should be aware that there are other platforms than their own. Try to be aware of when you're making an assumption about the architecture. If you can make it portable without breaking your program, then good. If not, document it-- and maybe add something like '#ifndef i386 / #error "See ARCHITECTURE NOTES in the docs" / #endif'.
Applications will only break if they relied on specific random ordering ACCROSS EXECUTIONS. E.g., if you dumped the contents of a hash into a file on two runs, and then compared, you may now get different ordering on identical data, whereas before you would (coincidentally) get the same random ordering and there would be no difference between the files. You probably shouldn't have been relying on this to begin with.
Actually, I was. I have one test suite for a system, in which I make a "reference run" that gets dumped to a file. Then I make changes, or adjust timings, and so forth, then repeat the reference run to make sure there's no regressions. I can't hardcode many of the results in the test suite, since they depend on a database that is changing daily (or more frequently).
Presuming the resume (well, mine is a CV) is going to reputable employment agencies,
People misunderstand. Things get screwed up. And if you post on dice.com or something, all bets are off. I've seen people with the best of intentions get into trouble by putting out a resume before they were ready to.
Which makes them badly written apps.
Yup. There's a lot of badly written apps out there.
The PPC can switch between endian states.
Yes, but the badly written apps are not going to be doing the work to switch endianness modes.
C is the biggest problem child. There's a whole lot of implications, but here's the most common ones:
Most of these are implicitly used without the programmer realizing it, for example, by forgetting to #include prototypes, or by storing a long in an int variable.
See also the Jargon File entry for vaxocentrism.
It's also frequently easy to get access to different machines. Check with your friends (hobbyists often have old Alphas or Suns, and PPCs are becoming more common), check at work, use a build farm like Sourceforge's, etc.
As the article observes, Linux (and open-source software in general) is not locked into the x86 architecture like Windows is.
While true in theory, a decent number of Linux apps assume they're on an x86. The big killer between x86 and PPC, I think, is byte order, but pointer sizes and what not may come into play as we approach the 64-bit era.
By the way: my post was intended to be more of humorous intent than serious application, but there may be some merit.
You may want to read up on scheduler algorithms... the traditional Unix scheduler is similar to this. Substitute "nice value" for "seniority", and adjust the PRI based on pages received rather than cycles consumed, and volunteers are essentially using yield, and you've got a pretty decent starting point.
If Wal-Mart implements self-destructing RFID tags, and Target doesn't, where am I shopping? But how can I know? The clerk certainly can't tell me, and managers are often misinformed about technology issues. (He may think I'm a tinfoil hat guy when I ask.)
So is it feasible for consumers to purchase RFID scanners? Can I tell if my own (or my friends') stuff is RFID tagged? (Can I use this to find if my associates are wearing women's underwear??? Step 3: Profit!)
Maybe local users' groups can pool together to get group-owned RFID scanners, like we used to do with re-inkers in the dot matrix days.
Here's how it differs. The program is doing something that is substantially different than what the user believes it is doing. If you go up to somebody who has the Gator forms handler installed, and say "What does that program do?" they'll say "It fills in forms." If you say, "Do you have any programs installed that alter website advertising?", they'll say "No."
I don't think that users should be expected to understand every aspect of a program's operation. But I think that the fact that Gator does something substantially different than what the user believes, and that this subversion is unrelated to and unnecessary for its primary task, then it's different.
It can be argued that the EULA gives them permission to do stuff. But there's good legal arguments (from my understanding, but IANAL) that EULAs are unenforcable (based on a general rule about non-negotiable contracts). So here's a question. Does the act of installing a program give it license to do whatever it wants, or is it only allowed to do stuff that is part of its advertised purpose?
Personally, I think that it should not. Did the judge make the right call? I don't know enough about law to answer that. But if the judge ruled in accordance with the law, then perhaps the law should be changed.
So do we know how to set up a proxy to allow banner ads from /. etc, but still block them from others?
I keep hearing this, and I'm not convinced.
I didn't see anything in the article about what versions of closed-source codebases they used for comparison. But I'd hypothesize that it's code that they've been contracted to analyze. That means it's probably development code in that event, too.
We can't gritch about them using Apache 2.1-dev unless we have reason to believe they didn't compare againt dev versions. We can gritch about not having this information.
Do you have any references for this event? I'd like to find out more. (References to the halting problem by itself are not necessary; just this event.)
dilbert tanked 'cuz . . .(dramatic pause)
it wasn't funny!
Personally, I didn't like it when I saw it during its run. After a time I figured out why: Loud Howard. For some reason, they decided to make this one-off gag (that wasn't very funny to begin with) into what was almost a main character. I'd wince every time he spoke on the main show. (This could have to do with my roommate, who suffered hearing loss from working on F-4s and turned the TV way up.) I wouldn't enjoy the show.
Now they're showing it on Comedy Central, and I'm convinced that they're compressing Loud Howard's voice. I still don't like the character, but my mood doesn't drop a few percent every time he drops. Now I do enjoy the show.
Or maybe it's because I've worked at some more big corps now and can better empathize.
If the whole world would be runned by a central computer, would it's OS be relevant if it only runs on a single box?
Sure it would... whenever it was upgraded, they'd have to take /. down during the upgrade!
had he talked about the whole system, I'm quite sure he'd have used GNU/*BSD.
I doubt it. BSD has its own history as an OS, apart from GNU. FreeBSD does borrow some GNU utilities: bc/dc, binutils, gcc, cpio, cvs, dialog, diff, gperf, grep, groff, gzip, man, patch, send-pr, sort, tar, texinfo, and libreadline. We have some GNU libs (such as libiberty and libregex) to support the GNU utils, although we have similar replacements for the rest of the OS. Many of these utilities were adopted later in *BSD's life. For example, gcc replaced pcc.
Most of the rest of the OS is ours. I don't have room to give a comprehensive list, but some key players include fileutils, shellutils, ssh, libc (and most other libs), netutils, vi, init, fsutils, sendmail, and named.
It would have been nice for you to mention that you're using a Mac, instead of obtusely implying it (8600, BBEdit Lite).
The section of OSX that copying a file involves is not BSD-related, as I understand it. It's Mach. (People who know more about OSX than I do, feel free to pipe up.) The kernel of OSX is not very BSD-based, and most of what you're talking about (HDD access, scheduling) takes place in the kernel. (To be fair, the scheduler that FreeBSD uses was adapted from Mach.)
The 8600 (which was discontinued over a half decade ago, by the way) is not even compatible with OSX. The minimum requirement for OSX is the Beige Power Mac G3. (See Apple's requirements page.) So, I'm guessing you put in a G3 daughterboard. (Find out about the 8600 and available daughterboards at lowendmac.com.) But OSX doesn't support processor upgrade cards. (First paragraph of the requirements page.) Maybe you didn't put in an upgrade card, and are using the mach_kernel for the 604 from the Darwin project like this guy did. Either way, you're still not using a supported system.
So, you're using unsupported hardware, and a BSD-related OS in an operation that's not related to the BSD bits, and using this to say that BSD sucks. Hmmm.
I'm surprised an 8600 w/ daughterboard (which one, by the way? The 233MHz with 512k of cache?) works at all with OSX. As for why it's slow for you, I can only hypothesize, since I'm not a Mac guy. (That's right, anybody can find this stuff out with a quick google search or two!) The G3 upgrade card is going to need an L2 cache enabler. Do you have one installed? Okay, how about this idea. I'm guessing that your old, discontinued, unsupported hardware uses a bus controller (or other critical chip) that is not being programmed optimally by OSX. Why? Because the programmer writing that code knew that the chip wasn't going to be supported!
My advice is to stick to using 9.1 on your 8600. And don't generalize about BSD from your situation; it's an extreme.
But I slept through a lot of my statistics class, so I don't know if this would work or not. But I did learn that statisticians have some powerful techniques at their disposal.
Also, carpool lanes are just as much about cramped parking in Metro areas as fossil fuel emmissions.
I don't understand this statement. Can you please elaborate?
I expect it would. In slow-and-go traffic, you get worse milage than if you can breeze right on along.
To take this to its logical conclusion: if retasking the HOV lane to a general-purpose lane would significantly reduce slow-and-go traffic, it would not only improve peoples' commute times, but may also lower emissions pollution.
I say "may", because if a lot of people use HOV in your area, and would switch to single-driver cars if there were no HOV lane, then the increase in the number of cars may outweigh the benefits of reduced emissions from all cars. But I doubt that's the case, at least not where I've driven with HOV lanes (Dallas and Silicon Valley).