Like a lot of other people, this update seems to have completely screwed up ethernet networking for me. A lot of the reports I've read
(Apple's siteSlashdot comment,
MacFixit article,
MacSlash,
etc) suggest that people with dual processor G4s running 400-500mhz are having a lot of problems, and a broken driver for the Intel gigabit ethernet chipset has been blamed -- though I haven't seen anything that conclusively says that this component is at fault. Other reports have come from people running faster G4s & PowerBooks, so if the Intel ethernet driver is a cause, it doesn't seem to be the only cause. All I can say personally is that my dual G4/450mhz is definitely messed up right now.
The best remedy I've seen so far is to restore the pre-10.2.8 version of the AppleGMACEthernet ethernet driver. If you can -- and for most people it'll be too late for this advice to do any good -- make a backup of the.kext driver before updgrading to 10.2.8, then use that to rebuild is things go awry. For everyone else, your best bet is to download it from Andrew McPherson's MIT site, either by establishing a dialup connection, by booting into OS9 and getting it from there, or by grabbing it with another machine and transferring it to your broken Mac by e.g. a burned CD, a Zip disc, etc.
mkdir ~/enet_backup
cd ~/enet_backup
wget http://web.mit.edu/apm/www/AppleGMACEthernet.tar.g z
# note -- doing the above without network access is left
# as an exercise for the reader. i happen to have a flash
# card reader, so can transfer it that way, but I was
# getting pretty desperate before that occurred to me.
# others might want to try burning a CD, or getting
# online from OS9, or a zip disc, or...
#...in any case, `wget` is about the only method that is
# almost guaranteed NOT to work right now...
This advice is close to that which McPherson suggested, but he recommended deleting the broken driver, and the commands I give above make a backup just in case. If all goes well you may remove that ~/enet_backup directory, but I have a hunch that somehow you're going to have to end up re-installing it, so keeping a copy around seems prudent to me -- and it's not like it even takes up that much space (well under a megabyte).
Other people have reported success with other solutions. One proposal was to run the command "ifconfig en0 media autoselect", but in my case that didn't work. Others have suggested rebooting, zapping the PRAM a few times, then letting the machine boot again; others have said that that didn't work either.
Replacing the driver, as described above, seems to be the remedy that has had the most success for the most users -- but even still, it isn't working for everybody. In my case, it has allowed me to reconnect to my PPPoE/
Consider yourself lucky that you weren't hit by the 10.2.8Ethernetbug. This thing has been a royal pain in the ass, and if you didn't make a backup of your ethernet driver before running the update, downloading a copy can be a real headache.
Apple fucked up big time on this update -- this is as bad as the iTunes update that had a broken rm -rf call in a shell script, because while no data seems to be lost here, getting the machine fixed can be non-trivial if you're no longer able to access the network to begin with.
Everyone fucks up sometimes. Yesterday was Apple's turn.
If your machine is hosed, here's Andrew's suggested fix:
wget http://web.mit.edu/apm/www/AppleGMACEthernet.tar.g z
# note -- doing the above without network access is left
# as an exercise for the reader. i happen to have a flash
# card reader, so can transfer it that way, but I was
# getting pretty desperate before that occurred to me.
# others might want to try burning a CD or something...
This advice is posted more or less verbatim as McPherson posted it. I haven't yet tried it myself, but so far it is the only remedy I've seen that seems like it'll work -- the ifconfig en0 media autoselect trick didn't fix the problem in my case, so I'm hoping that this takes care of it.
as you can see, the Dell is $835 more. now, let's try and be objective, something PCMAG disavowed in their introduction saying they took Apple's claims about the speed of the G5 "with a grain of salt". in other words, the test was designed to debunk Apple, thus throwing objectivity out the window.
Nah, cut them a little slack on this one: it's perfectly valid to take a position as your null hypothesis -- in this case, that Macs are always slower than PCs -- and them come up with a suite of tests that attempt to disprove that hypothesis. By concluding that the G5 is comparable to modern x86 machines, they refuted the null hypothesis and so are standing on perfectly defensible ground here.
Now if they'd started with a subjective null hypothesis -- "all mac users are neener-heads", or if their tests had done nothing to affirm or contractice their hypothesis, then okay you could blame them for being biased. But in this case that doesn't apply -- they stated their assumptions, then tested them. You could argue that the tests were bogus (all benchmarks are questionable), but at least they were consistent & repeatable.
I've seen far worse journalism / investigation than this, including from this magazine. The only achingly bad thing that jumped out at me from this article was the assertion that the Mac keyboard & single-button mouse are "bad" -- a purely subjective and easily refutable position (UI research indicates that single-button pointers are more intuitive for novice users; replacement input devices are cheap if it bothers you that much, yadda yadda yadda). Other than that, they seemed to be fairly careful about trying to quantify everything, which IMO absolves them from most accusations of bias.
Yeah, that's an update then -- before the upgrade uname -v gave "Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC ". So it got bumped by two point releases, and there's your reason for the reboot.
upgrades have involved reboots in the past because, to improve performace, Apple has implemented part of iTunes as kernel extensions, and any tampering with the kernel requires a fresh boot to ensure stability. Other updates may have been done out of ignorance or habit, but in the case of the iApps, the reboots have generally been unavoidable.
That said, did the 10.2.8 update involve any kernel changes? It's been long enough that there could be a point release to the kernel itself by now, not to mention any other updated kernel extensions. I haven't yet had a chance to inspect the bill of materials (hint: lsbom/Library/Receipts/fooApp.pkg to learn what was updated in a given package), but if anything in there touched the kernel, then a reboot really does has to happen.
At any rate, from the article: "People who are serious about getting the job done on time and under budget will use tools such as Visual Basic (controlled all the machines that decoded the human genome)."
This is all fine and good, but the machines that "decoded" the human genome were performing a simple task really and did not require much in the way of alternative paths or any complex programming. For simple tasks or projects, yes VB is pretty handy. For other tasks, or requirements that may need a bit more complex programming, VB will not cut it.
Err, I think that's exactly why Greenspun is sticking up for VB: in a traditional MVC system, the best language for the View portion should be a lightweight, easy to use language that, ideally, won't scare away your UI designers. VB is just fine for this. So is PHP. Perl might be a little bit scary, but it has so many great templating options that one of those should be used for the View portion anyway, not raw Perl.
For the other portions of MVC, where a more powerful language makes more sense, then yeah, VB might not be the best choice. If what you're trying to do is really complex, then maybe Java makes more sense, or mod_perl modules, or C/C++, or what have you. But then again, if all your system is doing is providing code to extract database queries, then again the problem isn't very complex, and there's no reason VB can't do a perfectly fine job of it.
The point of the journal entry isn't that VB is a "better" tool than Java, but that for a lot of the things people are writing software to do, a relatively simple tool like VB can do a perfectly adequate job of it, and that it is in fact overkill to bring in all the heavy machinery of a J2EE framework when all you're trying to do is wrap web pages around SQL calls.
Based on just this tiny swatch of information, I already know the aproximate area where he lives.
That, or you know that he likes hanging out in the Adams Morgan neighborhood of DC, which might or might not tell you anything. A similar sort of area in the Boston area might suggest that a lot of people "live" in Harvard Square, because there are a lot of shops & restaraunts there. Similar analysis would be similarly skewed for any other big city.
Adams Morgan and Harvard Square are both districts with eclectic restaraunts, similar kinds of shops, etc. I picture them both having bookstores like Borders, clothing (etc) stores like Urban Outfitters, record stores, etc. Basically the sort of stores you might expect to find in any college town, or in this case the part of a large city near a big university.
What we're seeing here isn't necessarily where an indication of geography (in spite of the obvious map), but of demographics: he's the sort of person that would prefer to spend his money in a place like Adams Morgan (or, at a guess, Harvard Square). That suggests certain things about his income, education, etc, but based on this data his home address could actually be fairly wide open to interpretation. A lot of people will travel to a neighborhood like this from other parts of a city, or from the suburbs, because neighborhoods like this are often the best place to find certain things.
Or at least, that's what I do: my neighborhood one town over from Cambridge MA has few interesting stores or restaraunts, so a lot of the time in neighborhoods like Harvard Square, Coolidge Corner, etc. You could make a slightly more accurate guess where I live based on where I usually fill up my gas tank, but then I happen to live down the street from one of the cheapest gas stations in the area, and I get the impression that a lot of people go out of their way to get gas there.
---
So anyway, my point is that you're right, you can draw all sorts of inferences based on the presented patterns, but the nature of those patterns might not be obvious, or at least is a bit more complicated than simply assuming that the high concentration of transactions in a given neighborhood means that the person lives in that neighborhood. This, in my opinion, makes the data both more and less interesting...
This isn't exactly a new idea. The most prominent antecedent for this is Gordon Bell's MyLifeBits project at Microsoft Research. But even that isn't original -- Bell is working against ideas first presented in an article Vannevar Bush wrote for the July 1945 issue of Atlantic Monthly, As We May Think.
Bush's essay is really fascinating to read: he envisions a magical desk that could record all a person's thoughts & encounters, and provide the ability to browse that library through a special screen on the device. Keep in mind that this was in 1945, right at the beginning of the computer era, when these machines were the size of buildings, far more complicated to operate, and nowhere near powerful enough. Now, half a century later, Bell feels that the technology is finally at the point where Bush's ideas can be implemented. Think what you will of Microsoft, or of the "big brother" implications of such a machine -- the very fact that this sort of thing is being put into practice is quite impressive.
Anyone working on such omnipresent recording & retrieval systems needs to be aware of this prior art.
Okay, I stand corrected then. Still, the way that the story is presented still smells a lot like FUD to me, even if it wasn't intended that way. But then I guess that's yet another mark of the difference between a professionally done journalism site on one hand, and Slashdot on the other...:-)
Hold on while i go patent the alphabet as a filing system. And copyright it. Every keyboard company will be paying me money... heh heh heh....
Luckily for the keyboard companies, they had the foresight to agree on an arrangement that is not actually in alphabetical order -- take that, profiteers! heh heh heh...:-)
Is the submitter an employee of Intel? Isn't this classic FUD tactics? "Wait, don't buy that guy's product, we're coming up with something even more super duper in just a few months...".
I smell a rat.
There may be nothing malicious to this, but the specific exhortation not to buy a competitor's product just because of the possible future abilities of some other company's products just turns me off. Of course they're all going to have something better in six months, a year, a decade, etc.
The only way to make sense of it all is to compare apples to apples: the Althon64 & PowerPC G5 are both on the market now, or about to be, so comparisons there are valid. Comparisons to what Intel might possibly be making later are just... well, they seem very questionable to me.
(And since I've been pointing fingers willy nilly, I have no vested interest in whether Intel or AMD does better in the market. I mostly use Macs and am indifferent to who has their brand name on any x86 hardware I might use to run Linux...)
No exactly what you're talking about, but don't a lot of dynamic languages allow you to do this sort of thing already?
I thought one of the Big Win features of Common Lisp was the ability to dynamically generate & run code on the fly, which is basically what you're talking about.
Likewise, Perl & Python let you do similar things with the eval amd lambda functions -- build up a data structure or code block, store it in a variable then eval{...} it as you go.
Granted, there's no compilation in the C/C++ sense with Perl & Python, so no external software is needed. I gather the same is true with CL, but I've never used that language. Still, it seems like there are ways to do what you're describing, and they allow programmers to pull off some interesting things sometimes. It sounds like you may want to read up on functional programming:-)
I'm really not trying to troll, honest. I just think that the "$foo considered harmful" meme is frequently taken much too far.
The original points behind essays such as Dijkstra's "GOTO considered harmful" or Tom Christensen's "CSH considered harmful" may be valid, but IMO this kind of polemic argument often goes out of its way to ignore any of the redeeming qualities in the harmful thing being considered. This kind of thinking, in my opinion, can lead to "forbidden knowledge" and, ultimately, a sense of ignorance that is worse than the original problem.
It's reflexive, absolutist thinking that bothers me, not the GOTO argument itself. GOTO is harmful, sure, but there are defensible uses for it. Knowledge is being aware of the rules, guidelines, and best practices; wisdom is knowing when to ignore them.
It's impossible to write a complex program without using GOTOs
I call bullshit on you. There is nothing about fortran that makes GOTOs any more necessary than they are in C (which is an argument in and of itself... however I come down on the side of "never use them").
You do realize, of course, that once your compiler gets its scruffy mitts on your code, that it all gets turned into GOTOs and JUMP statements at the assembly & machine code level, right?
GOTO is a perfectly necessary construct, and in the right circumstances, completely defensible.
When Dijkstra said that "GOTO is considered harmful", I suspect that he didn't mean to banish it altogether. There's lots of "harmful" things that we deal with every day without batting an eyelid: operating a motor vehicle, working with dangerously high voltage electrical systems (like, say, a computer, or a toaster), handling highly flammable substances (paper burns, man, and those books of you're are just made out of the stuff). etc.
The solution isn't to avoid all harmful things, like GOTO or toasters, but to design our systems such that we can take advantage of the useful properties of these things while shielding us from the dangerous bits. That's why the toaster's heating element is hard to reach (but why pulling out your toast with a fork is dangerous -- but sometimes seems necessary), and that's why most of your programs' GOTO statements are wrapped up in calls under the compiler level (but why high level languages often have GOTO constructs that can also be dangerous, but sometimes make things easier to solve).
A firm, unwavering belief in a slogan such as "GOTO considered harmful" is a sure sign that you've missed some of the subtlety that any catch phrase like this is likely to have elided. Don't fall into that trap. GOTO may be harmful, but that doesn't mean that it doesn't have a necessary place. Students should be taught not to reflexively avoid the harmful thing, but to understand what it is, how it is needed, and what can go wrong when using it.
FWIW, that's not how I remember it -- the original DeCSS was (I assume) a C program, and there was a trend of re-implementing it in different languages to keep it from being eradicated. The Perl example you cite was the shortest implementation, but I'm pretty sure it wasn't the original.
I can't find direct citations for this, but the "remove cascading stylesheets" DeCSS -- which came out as a protest to the original DeCSS decoder -- is talked about in this page, which is dated 16 Feb 2000. There's a reference to the 7 line Perl version from this article, dated 8 Mar 2001, and in this Wired article from Jun 2001.
This is enough to convince me that the original DeCSS wasn't as you describe here. I'm still not sure if it was Perl or not, but it wasn't the 7 liner that came out over a year later than the original.
----
REPOST: the original version of this comment had a broken anchor tag, which is corrected here. Feel free to mod the other version into oblivion...
FWIW, that's not how I remember it -- the original DeCSS was (I assume) a C program, and there was a trend of re-implementing it in different languages to keep it from being eradicated. The Perl example you cite was the shortest implementation, but I'm pretty sure it wasn't the original.
This is enough to convince me that the original DeCSS wasn't as you describe here. I'm still not sure if it was Perl or not, but it wasn't the 7 liner that came out over a year later than the original.
I only noted that because I've been asked for it before. The only reason I didn't paste it was because <irony>Slashdot makes it a pain in the ass to paste source code samples into comments </irony>. But you're right, it's trivial, and anyone could replicate it, I was just trying to be helpful...
Wednesdays are pretty much in the middle of the range (the mean is 824.9).
The bigger trend I've seen was a big spike back in May, but the rate has sloped off considerably since then, as this chart of month over month spam trends shows (line length is again divided by 25):
0045 -- 2003 Sep x
0224 -- 2003 Aug xxxxxxxx
0252 -- 2003 Jul xxxxxxxxxx
0626 -- 2003 Jun xxxxxxxxxxxxxxxxxxxxxxxxx
1602 -- 2003 May xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxx
0734 -- 2003 Apr xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
0439 -- 2003 Mar xxxxxxxxxxxxxxxxx
0289 -- 2003 Feb xxxxxxxxxxx
0235 -- 2003 Jan xxxxxxxxx
0283 -- 2002 Dec xxxxxxxxxxx
(The script that generated this is available on request.) A major cause for this change in trends may be a change in email address around then, but even before the switch I was seeing a dropoff in the number of spams I was receiving. If this pattern is more general than just my mailbox, I have no idea what's causing it.
Disclaimer: no general trends are implied, this is just "back of the envelope" analysis of the spam mail I personally receive. As noted above, if anyone wants the shell scripts that generate these charts, you're welcome to them -- they're just a few lines of Bourne code that scan over my mbox mailboxes. If you use something other than mbox mail storage, the script may or may not do you any good, but if you want it, ask.:-)
Remapping X11 keymaps on most platforms is easy, as this tool shows, but there seem to be other factors involved on the Mac. It's been a while since I read about this, but it was discussed on Apple's x11-users list -- the archives may have more details, though a brief poke at Google isn't turning up any hits (yay password protected mailing list archives -- what a great way to diminsh the value of the archive...).
I was told about this property of Apple keyboards in the context of discussion about keyboard maps and X11. Apparently people have wanted to, for example, swap [ctrl] and [caps lock] for Emacs etc, but haven't been able to do so because of the weird codes that Apple keyboards transmit. All I know is that Apple keyboards, apparently, deviate from the spec, but I can't give any more detail than that...
They may have fixed this by now -- I did a CVS update over the weekend, and got a new gcc-3.3 tree in my CVS repository:
% ls/sw/fink/10.* /sw/fink/10.2:
CVS
local
stable
unstable
/sw/fink/10.2-gcc3.3:
CVS
stable
unstable
/sw/fink/10.3:
CVS
IDEAS
If you installed the GCC3.3 update before learning about the warning, try doing a CVS update for Fink with `sudo fink -y selfupdate` (or maybe `sudo fink -y selfupdate-cvs`, depending on options you may have selected in the past). This may force you to start rebuilding much [all?] installed software based on the GCC3.3 updated versions, provided that those versions are available yet.
This may get you by until an announcement comes along on the Fink news page.
Slashdot Mirror
Like a lot of other people, this update seems to have completely screwed up ethernet networking for me. A lot of the reports I've read (Apple's site Slashdot comment, MacFixit article, MacSlash, etc) suggest that people with dual processor G4s running 400-500mhz are having a lot of problems, and a broken driver for the Intel gigabit ethernet chipset has been blamed -- though I haven't seen anything that conclusively says that this component is at fault. Other reports have come from people running faster G4s & PowerBooks, so if the Intel ethernet driver is a cause, it doesn't seem to be the only cause. All I can say personally is that my dual G4/450mhz is definitely messed up right now.
The best remedy I've seen so far is to restore the pre-10.2.8 version of the AppleGMACEthernet ethernet driver. If you can -- and for most people it'll be too late for this advice to do any good -- make a backup of the .kext driver before updgrading to 10.2.8, then use that to rebuild is things go awry. For everyone else, your best bet is to download it from Andrew McPherson's MIT site, either by establishing a dialup connection, by booting into OS9 and getting it from there, or by grabbing it with another machine and transferring it to your broken Mac by e.g. a burned CD, a Zip disc, etc.
Here are the repair steps, as slightly modified from McPherson's suggestion at Apple's site:
This advice is close to that which McPherson suggested, but he recommended deleting the broken driver, and the commands I give above make a backup just in case. If all goes well you may remove that ~/enet_backup directory, but I have a hunch that somehow you're going to have to end up re-installing it, so keeping a copy around seems prudent to me -- and it's not like it even takes up that much space (well under a megabyte).
Other people have reported success with other solutions. One proposal was to run the command "ifconfig en0 media autoselect", but in my case that didn't work. Others have suggested rebooting, zapping the PRAM a few times, then letting the machine boot again; others have said that that didn't work either.
Replacing the driver, as described above, seems to be the remedy that has had the most success for the most users -- but even still, it isn't working for everybody. In my case, it has allowed me to reconnect to my PPPoE/
Consider yourself lucky that you weren't hit by the 10.2.8 Ethernet bug. This thing has been a royal pain in the ass, and if you didn't make a backup of your ethernet driver before running the update, downloading a copy can be a real headache.
Apple fucked up big time on this update -- this is as bad as the iTunes update that had a broken rm -rf call in a shell script, because while no data seems to be lost here, getting the machine fixed can be non-trivial if you're no longer able to access the network to begin with.
Everyone fucks up sometimes. Yesterday was Apple's turn.
This advice is posted more or less verbatim as McPherson posted it. I haven't yet tried it myself, but so far it is the only remedy I've seen that seems like it'll work -- the ifconfig en0 media autoselect trick didn't fix the problem in my case, so I'm hoping that this takes care of it.
What a royal pain in the ass...
Nah, cut them a little slack on this one: it's perfectly valid to take a position as your null hypothesis -- in this case, that Macs are always slower than PCs -- and them come up with a suite of tests that attempt to disprove that hypothesis. By concluding that the G5 is comparable to modern x86 machines, they refuted the null hypothesis and so are standing on perfectly defensible ground here.
Now if they'd started with a subjective null hypothesis -- "all mac users are neener-heads", or if their tests had done nothing to affirm or contractice their hypothesis, then okay you could blame them for being biased. But in this case that doesn't apply -- they stated their assumptions, then tested them. You could argue that the tests were bogus (all benchmarks are questionable), but at least they were consistent & repeatable.
I've seen far worse journalism / investigation than this, including from this magazine. The only achingly bad thing that jumped out at me from this article was the assertion that the Mac keyboard & single-button mouse are "bad" -- a purely subjective and easily refutable position (UI research indicates that single-button pointers are more intuitive for novice users; replacement input devices are cheap if it bothers you that much, yadda yadda yadda). Other than that, they seemed to be fairly careful about trying to quantify everything, which IMO absolves them from most accusations of bias.
Yeah, that's an update then -- before the upgrade uname -v gave "Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC ". So it got bumped by two point releases, and there's your reason for the reboot.
upgrades have involved reboots in the past because, to improve performace, Apple has implemented part of iTunes as kernel extensions, and any tampering with the kernel requires a fresh boot to ensure stability. Other updates may have been done out of ignorance or habit, but in the case of the iApps, the reboots have generally been unavoidable.
That said, did the 10.2.8 update involve any kernel changes? It's been long enough that there could be a point release to the kernel itself by now, not to mention any other updated kernel extensions. I haven't yet had a chance to inspect the bill of materials (hint: lsbom /Library/Receipts/fooApp.pkg to learn what was updated in a given package), but if anything in there touched the kernel, then a reboot really does has to happen.
Err, I think that's exactly why Greenspun is sticking up for VB: in a traditional MVC system, the best language for the View portion should be a lightweight, easy to use language that, ideally, won't scare away your UI designers. VB is just fine for this. So is PHP. Perl might be a little bit scary, but it has so many great templating options that one of those should be used for the View portion anyway, not raw Perl.
For the other portions of MVC, where a more powerful language makes more sense, then yeah, VB might not be the best choice. If what you're trying to do is really complex, then maybe Java makes more sense, or mod_perl modules, or C/C++, or what have you. But then again, if all your system is doing is providing code to extract database queries, then again the problem isn't very complex, and there's no reason VB can't do a perfectly fine job of it.
The point of the journal entry isn't that VB is a "better" tool than Java, but that for a lot of the things people are writing software to do, a relatively simple tool like VB can do a perfectly adequate job of it, and that it is in fact overkill to bring in all the heavy machinery of a J2EE framework when all you're trying to do is wrap web pages around SQL calls.
"Horses for courses."
That, or you know that he likes hanging out in the Adams Morgan neighborhood of DC, which might or might not tell you anything. A similar sort of area in the Boston area might suggest that a lot of people "live" in Harvard Square, because there are a lot of shops & restaraunts there. Similar analysis would be similarly skewed for any other big city.
Adams Morgan and Harvard Square are both districts with eclectic restaraunts, similar kinds of shops, etc. I picture them both having bookstores like Borders, clothing (etc) stores like Urban Outfitters, record stores, etc. Basically the sort of stores you might expect to find in any college town, or in this case the part of a large city near a big university.
What we're seeing here isn't necessarily where an indication of geography (in spite of the obvious map), but of demographics: he's the sort of person that would prefer to spend his money in a place like Adams Morgan (or, at a guess, Harvard Square). That suggests certain things about his income, education, etc, but based on this data his home address could actually be fairly wide open to interpretation. A lot of people will travel to a neighborhood like this from other parts of a city, or from the suburbs, because neighborhoods like this are often the best place to find certain things.
Or at least, that's what I do: my neighborhood one town over from Cambridge MA has few interesting stores or restaraunts, so a lot of the time in neighborhoods like Harvard Square, Coolidge Corner, etc. You could make a slightly more accurate guess where I live based on where I usually fill up my gas tank, but then I happen to live down the street from one of the cheapest gas stations in the area, and I get the impression that a lot of people go out of their way to get gas there.
---
So anyway, my point is that you're right, you can draw all sorts of inferences based on the presented patterns, but the nature of those patterns might not be obvious, or at least is a bit more complicated than simply assuming that the high concentration of transactions in a given neighborhood means that the person lives in that neighborhood. This, in my opinion, makes the data both more and less interesting...
Bush's essay is really fascinating to read: he envisions a magical desk that could record all a person's thoughts & encounters, and provide the ability to browse that library through a special screen on the device. Keep in mind that this was in 1945, right at the beginning of the computer era, when these machines were the size of buildings, far more complicated to operate, and nowhere near powerful enough. Now, half a century later, Bell feels that the technology is finally at the point where Bush's ideas can be implemented. Think what you will of Microsoft, or of the "big brother" implications of such a machine -- the very fact that this sort of thing is being put into practice is quite impressive.
Anyone working on such omnipresent recording & retrieval systems needs to be aware of this prior art.
:-)
Okay, I stand corrected then. Still, the way that the story is presented still smells a lot like FUD to me, even if it wasn't intended that way. But then I guess that's yet another mark of the difference between a professionally done journalism site on one hand, and Slashdot on the other... :-)
Luckily for the keyboard companies, they had the foresight to agree on an arrangement that is not actually in alphabetical order -- take that, profiteers! heh heh heh... :-)
Is the submitter an employee of Intel? Isn't this classic FUD tactics? "Wait, don't buy that guy's product, we're coming up with something even more super duper in just a few months...".
I smell a rat.
There may be nothing malicious to this, but the specific exhortation not to buy a competitor's product just because of the possible future abilities of some other company's products just turns me off. Of course they're all going to have something better in six months, a year, a decade, etc.
The only way to make sense of it all is to compare apples to apples: the Althon64 & PowerPC G5 are both on the market now, or about to be, so comparisons there are valid. Comparisons to what Intel might possibly be making later are just... well, they seem very questionable to me.
(And since I've been pointing fingers willy nilly, I have no vested interest in whether Intel or AMD does better in the market. I mostly use Macs and am indifferent to who has their brand name on any x86 hardware I might use to run Linux...)
Or for that matter, they don't seem to do well with groceries either.
China is getting involved in the Galileo project? What lucky timing: On Sunday, September 21, NASA's Galileo spacecraft will end 14 years of exploration in spectacular fashion: by crashing into Jupiter.
Can we get them to have the check sent by overnight mail, or would a wire transfer be easier at this late stage?
I thought one of the Big Win features of Common Lisp was the ability to dynamically generate & run code on the fly, which is basically what you're talking about.
Likewise, Perl & Python let you do similar things with the eval amd lambda functions -- build up a data structure or code block, store it in a variable then eval{...} it as you go.
Granted, there's no compilation in the C/C++ sense with Perl & Python, so no external software is needed. I gather the same is true with CL, but I've never used that language. Still, it seems like there are ways to do what you're describing, and they allow programmers to pull off some interesting things sometimes. It sounds like you may want to read up on functional programming :-)
Depends on your line of work, I suppose.
I once saw the following humorous graffiti on the blackboard in a university math department's classroom:
It's funny because it's true! :-)
:-)
I'm really not trying to troll, honest. I just think that the "$foo considered harmful" meme is frequently taken much too far.
The original points behind essays such as Dijkstra's "GOTO considered harmful" or Tom Christensen's "CSH considered harmful" may be valid, but IMO this kind of polemic argument often goes out of its way to ignore any of the redeeming qualities in the harmful thing being considered. This kind of thinking, in my opinion, can lead to "forbidden knowledge" and, ultimately, a sense of ignorance that is worse than the original problem.
It's reflexive, absolutist thinking that bothers me, not the GOTO argument itself. GOTO is harmful, sure, but there are defensible uses for it. Knowledge is being aware of the rules, guidelines, and best practices; wisdom is knowing when to ignore them.
You do realize, of course, that once your compiler gets its scruffy mitts on your code, that it all gets turned into GOTOs and JUMP statements at the assembly & machine code level, right?
GOTO is a perfectly necessary construct, and in the right circumstances, completely defensible.
When Dijkstra said that "GOTO is considered harmful", I suspect that he didn't mean to banish it altogether. There's lots of "harmful" things that we deal with every day without batting an eyelid: operating a motor vehicle, working with dangerously high voltage electrical systems (like, say, a computer, or a toaster), handling highly flammable substances (paper burns, man, and those books of you're are just made out of the stuff). etc.
The solution isn't to avoid all harmful things, like GOTO or toasters, but to design our systems such that we can take advantage of the useful properties of these things while shielding us from the dangerous bits. That's why the toaster's heating element is hard to reach (but why pulling out your toast with a fork is dangerous -- but sometimes seems necessary), and that's why most of your programs' GOTO statements are wrapped up in calls under the compiler level (but why high level languages often have GOTO constructs that can also be dangerous, but sometimes make things easier to solve).
A firm, unwavering belief in a slogan such as "GOTO considered harmful" is a sure sign that you've missed some of the subtlety that any catch phrase like this is likely to have elided. Don't fall into that trap. GOTO may be harmful, but that doesn't mean that it doesn't have a necessary place. Students should be taught not to reflexively avoid the harmful thing, but to understand what it is, how it is needed, and what can go wrong when using it.
FWIW, that's not how I remember it -- the original DeCSS was (I assume) a C program, and there was a trend of re-implementing it in different languages to keep it from being eradicated. The Perl example you cite was the shortest implementation, but I'm pretty sure it wasn't the original.
I can't find direct citations for this, but the "remove cascading stylesheets" DeCSS -- which came out as a protest to the original DeCSS decoder -- is talked about in this page, which is dated 16 Feb 2000. There's a reference to the 7 line Perl version from this article, dated 8 Mar 2001, and in this Wired article from Jun 2001.
This is enough to convince me that the original DeCSS wasn't as you describe here. I'm still not sure if it was Perl or not, but it wasn't the 7 liner that came out over a year later than the original.
----
REPOST: the original version of this comment had a broken anchor tag, which is corrected here. Feel free to mod the other version into oblivion...
FWIW, that's not how I remember it -- the original DeCSS was (I assume) a C program, and there was a trend of re-implementing it in different languages to keep it from being eradicated. The Perl example you cite was the shortest implementation, but I'm pretty sure it wasn't the original.
I can't find direct citations for this, but the "remove cascading stylesheets" DeCSS -- which came out as a protest to the original DeCSS decoder -- is talked about in this page, which is dated 16 Feb 2000. There's a reference to the 7 line Perl version from this article, dated 8 Mar 2001, and in this Wired article from Jun 2001.
This is enough to convince me that the original DeCSS wasn't as you describe here. I'm still not sure if it was Perl or not, but it wasn't the 7 liner that came out over a year later than the original.
I only noted that because I've been asked for it before. The only reason I didn't paste it was because <irony>Slashdot makes it a pain in the ass to paste source code samples into comments </irony>. But you're right, it's trivial, and anyone could replicate it, I was just trying to be helpful...
I've been saving most of my spam for the past year or so. A quick scan of my spam folder shows the following breakdown, sorted by frequency:
Or, for the same data as a histogram (line length divided by 25):
Wednesdays are pretty much in the middle of the range (the mean is 824.9).
The bigger trend I've seen was a big spike back in May, but the rate has sloped off considerably since then, as this chart of month over month spam trends shows (line length is again divided by 25):
(The script that generated this is available on request.) A major cause for this change in trends may be a change in email address around then, but even before the switch I was seeing a dropoff in the number of spams I was receiving. If this pattern is more general than just my mailbox, I have no idea what's causing it.
Disclaimer: no general trends are implied, this is just "back of the envelope" analysis of the spam mail I personally receive. As noted above, if anyone wants the shell scripts that generate these charts, you're welcome to them -- they're just a few lines of Bourne code that scan over my mbox mailboxes. If you use something other than mbox mail storage, the script may or may not do you any good, but if you want it, ask. :-)
Remapping X11 keymaps on most platforms is easy, as this tool shows, but there seem to be other factors involved on the Mac. It's been a while since I read about this, but it was discussed on Apple's x11-users list -- the archives may have more details, though a brief poke at Google isn't turning up any hits (yay password protected mailing list archives -- what a great way to diminsh the value of the archive...).
*shrug*
I was told about this property of Apple keyboards in the context of discussion about keyboard maps and X11. Apparently people have wanted to, for example, swap [ctrl] and [caps lock] for Emacs etc, but haven't been able to do so because of the weird codes that Apple keyboards transmit. All I know is that Apple keyboards, apparently, deviate from the spec, but I can't give any more detail than that...
If you installed the GCC3.3 update before learning about the warning, try doing a CVS update for Fink with `sudo fink -y selfupdate` (or maybe `sudo fink -y selfupdate-cvs`, depending on options you may have selected in the past). This may force you to start rebuilding much [all?] installed software based on the GCC3.3 updated versions, provided that those versions are available yet.
This may get you by until an announcement comes along on the Fink news page.