Sorry, my I wasn't intending to suggest getting poutine at McDo or Burger King. By "fast food" I meant places like La Belle Province or LaFleur's, or anyone of a billion independent casse-croute places that can be found in Quebec (or, as someone else mentioned elsewhere, off a chip wagon in Ottawa).
Was never that big a fan of poutine, but my Saturday nights at Foufounes Electriques were never complete without some all-dressed steamies (hot dogs) just after 3AM on Boul. St-Laurent. Those really hit the spot.
It seems unusual to me that it seems so much internet work is being done in CS. Maybe California has more of a communications emphasis, but here at UIUC we do practically no web programming, yet this is supposed to be the 2nd best school for CS.
(networking & data communications) != (web programming)
And today, I'm left contemplating whether I should change my default shell in Linux to tcsh. But that would mean to change lots of files: Just imagine, you donwload something nice, do "./configure" and - voila - syntax error.
Huh? configure scripts should have
#!/bin/sh
as its first line, so it really shouldn't be a problem. (/bin/sh is usually just a link to bash on Linux systems.)
Broadcom isn't exactly the most open company. At one company I worked for, we were using some Broadcom chips and the datasheets we got from them (as PDF) had a watermark on each and every page that said "Confidential for {Name of Company I worked for}", as well as a password for each file (a different password for each file, no less).
Not that they are entirely alone. We also had hard copy of Intel datasheets for some Ethernet chips that had bright yellow covers that detailed who they had been given to, and what to do if you 'found' them (ie return them to Intel), etc. They also had the ominous warning of "DO NOT REPRODUCE". A fellow I worked with was working on the driver for one of these Intel devices, and was about to be married. I did jokingly ask him if his fiancee knew that he was under strict orders from Intel not to have children.:-)
But the question is what % of readers of slashdot can actually read morse code or even binary?
I personally think this whole geek/binary thing is a bit silly. As someone who does works on a regular basis playing with bits (working on embedded systems, and most of that is low-level code like device drivers), I use hex all the time instead of binary. It's a lot easier to represent stuff in hex (8 digits instead of 32 for a 32-bit value), and it doesn't take long to learn how to read hex and "see" which bits are set or cleared.
For those in a position to select one of these embedded processors, they already know all of this.
Umm, I believe this assumption is not a good one. Lots of people working in embedded systems believe some of these myths. This article is aimed at making sure everyone in the field is aware of these pitfalls. For example, I've seen lots of CPU selector charts specify Dhyrstone MIPS to indicate CPU horsepower.
Back in the Fall of 1997, I remember getting a newsletter from the Motorola semiconductor group touting that they had just shipped their 1 or 2-billionth 6805 microcontroller (can't remember the number, couldn't find it on their web site). I would imagine they've shipped a few more in the 5.5 years since then.
Sorry for taking so long to reply - had other things to do.
I found three links in a row on the Rense website referring to the possibility of SARS being a man-made bioweapon. A lot of the information from the three links is the same, but each does contain additional information.
I don't have time to research all of the claims made in those links, but some things did stick out to me:
They keep quoting Nikolai Filatov as saying he thinks the virus is man-made because "there is no vaccine for this virus, its make-up is unclear, it has not been very widespread and the population is not immune to it." with no further explanation. That quote raises a few points for me.
Why does the lack of a vaccine indicate it is man-made? Before we (humans) created the first vaccine, there were no vaccines at all - I certainly don't think that implies all viruses that existed before that point in time were man-made.
How does an "unclear makeup" indicate it is man-made? If the virus contains DNA that isn't similar to anything else ever sequenced (if that is what is meant), I don't see how that would indicate it necessarily being man-made (I'm not saying it isn't possible, just that I don't see how it is proof).
I'm also not clear how the population not being immune to it indicates it is man-made. Unfortunately, I'm not an epidemiologist (IANAE?), so it is hard for me to comment on this.
I also would like more information about why the virus being a supposed "cocktail of measles and mumps" could never occur in nature. Again, I'm not saying what he says isn't possible, I just what to know on what basis this claim is made.
I'm not saying that what they are claiming isn't true. I don't know. I do know that if I was hearing a lot of other scientists agreeing with this, I would probably pay a lot more attention to it. It would be nice to have a rebuttal (or confirmation) from a respected virologist, instead of just information provided by a site (rense.com) that also includes stories about Ernst Zundel (holocaust denier) and UFOs.
The complexities of it also tend to suggest human manufactured.
I wouldn't use complexity as any sort of argument for a human's hand in this. If anything, I would argue that complexity would point away from an artificial source and towards a natural one.
For all our advances in understanding of molecular biology, we still know far less than we don't know, especially about protein structure and fuction. If we knew enough about that, then most diseases for which we have identified the genes involved would be cured by now. Sequencing genes is relatively easy, identifying what the gene does is harder, but figuring out exactly how the protein product of the gene actually works (and how a mutation affects that functioning) is by far the hardest.
Human intervention in creating a virus would most likely take the form of "let's take this gene from another virus or organism and put it in this other virus". Things like that aren't too hard to identify by DNA sequence analysis (relatively simple pattern matching, after all). I'm sure after they sequenced the DNA of the virus, they started comparing it to other known sequences. (Interesting side note - I actually had a class with one of the people who sequenced the virus DNA - he was taking a few qualifying courses before starting his grad studies in molecular biology, and I was finishing my undergrad in biochemistry. It was funny to see the name and recognize the face almost 12 years later.)
pre-increment is usually slightly faster than post increment. I can't rememenber the details, I'm sorry, but it's something about not making an internal copy of the variable be incrementing. This can be material if you're trying to get every bit of performance out of a piece of code.
In C, pre- and post-increment doesn't make a difference. Likewise, when using plain integral types in C++ (int, etc), it still doesn't make a difference. Where is does make a difference is when you get into operator overloading in C++.
Pre-increment increments the object and then evaluates to the new value. Post-increment increments the object and then evaluates to the *OLD* value of the object.
Overloading the pre-increment value is pretty easy - do the operation and return the updated 'this' (by reference).
However, overloading the post-increment requires you to make a *copy* of the original object before incrementing it, so that you can return the original value, not the new one. Thus the body of the post-increment function would look something like: type orig = *this; ++(*this); return orig;
Thus, using the post-increment will lead to a copy-constructor being invoked. Since it doesn't hurt to use one form or the other if all you are doing is incrementing and nothing else, a lot of C++ programmers just use ++i;
in preference to i++;
Of course, if the operators and constructors are all inlined functions and the optimizer is good, hopefully all of the extra code generated to make a copy of the un-needed copy of the object will be removed, anyway. But why take the chance?
Having read this book some years back about the relatively early development of NT, I remember Cutler being very anti-Unix. It was the OS that VMS was compared & contrasted with, and is still the OS that NT is put up against.
The book made it sound like Cutler didn't think much of Unix, and I remember comments along the lines of him thinking Unix had been put together by a bunch of University hackers and wasn't that well designed (of course compared to the OSes he had helped developed). It is kind of interesting to consider that now in light of the directions things have gone with respect to Linux et al. since the book was published.
Nevertheless, the book was an interesting read and seemed much less 'rah-rah' and awe-struck than these two articles.
Think about it, that would be the most obnoxious feature ever.
How so? About the only time my stylus is more than a few feet away from my Palm is when I have left it somewhere and walked away or lent it to someone else and they walked away with it. Even in the second case, I would only loan it to someone who would use it for a few minutes and give it back (ie they shouldn't get up and walk away with it).
Anyone who frequently has their stylus separated from their PDA/cell/etc can just disable the warning by always leaving the stylus set to 'un-tethered' through a software setting.
I expect such a feature to be fully customizable through the software - in addition to being able to disable it, I would want to control what type of warnings (visual, audible (including volume)), how long it has to be out of range before the warning occurs, etc.
Actually, I think it does. There's really not much a designer can do about a stylus apart from tethering it to the PDA, but I think most would agree that a tether would suck. It's the only necessarily separate object, and bound to be lost. Seems like a smart thing to do, including multiples of an easily lost object...
One design suggestion: how about some form of electronic tether? Perhaps something like one of akin to an RFID tag in the stylus. The 'mother-device' (PDA, phone, what-have-you) could check for proximity at an certain interval (every few seconds?) and start to complain (beep, warning message) if the stylus gets out of range. Of course, there would need to be ways to 'un-tether' and 're-tether' the stylus (changing to a new one, lending yours to someone else, etc.) through the SW. I don't know if this is feasible yet (size, cost, etc), but it's just an idea.
If they taught you 68k assembly the way they taught me x86 assembly, then you have ENTIRELY missed the point.
I learned x86 assembly as part of a first year 'Introduction to Computer Organization' course, in which the lectures focussed on computer architecture, including things like instruction set architectures, micro-instructions, etc., and the labs were programming in x86 assembly. I found the two complemented each other nicely.
The point wasn't to teach you how to program a 68k or x86 processor in assembly language. It was to give you some insight into how a processor operates and how it is programmed at a lower level than code in C, C++, Pascal, or what have you.
For what it's worth, learning 68k assembly in school would have helped me a lot more than x86. I've had to read and write a lot more of the former than the latter in my professional career. Of course, learning any assembly language, even a crappy Intel instruction set, made it a lot easier to learn (and appreciate) a better designed instruction sets and processors like 68k and PowerPC.:-)
Heck, here are some more examples. I remember a memory management assignment in an data structures & algorithms class where we were allocating 'memory' from an array of integers. Another assignment in the same class had us doing different sorting algorithms by hand. For compiler design, our compilers had to output assembly code for a fictitious processor. The point was learning the concepts, not being trained to do a specific job. And I also remember people in those classes who didn't get that.
Database A is in the possession of the merchant. Database B is in the possession of the credit card company.
I'm not sure if the credit card company receives much more than the amount, date, merchant identification, and the credit card #. Lots of smaller stores just have credit card/debit card terminal that they just swipe the card and enter a total amount - only enough for the credit card company to know where, when, and how much, but not exactly what.
This is why lots of stores have introduced "loyalty" programs of some sort, each with a membership card or number. They give you some small perks (discounts on some products, reward points for total spending, etc), in exchange for tracking your spending habits at their stores.
In Canada, AirMiles (nothing to do with any airlines frequent flier program) does this for a group of merchants (including The Bay/Zellers and Shell). In this case, the merchants get an even better picture of these consumers... Unless you do what my mother and sister do: my mother uses my sister's AirMiles number to help her build up points more quickly. Of course AirMiles just ends up with the spending habits of a person who can shop at two Safeways in two different timezones at the same time. I guess they could separate the info based on location, until one visits the other...
Slashdot Mirror
1992 must have indeed rocked for you, if you had an 840AV, since that machine wasn't released until July of 1993. :-)
g e=gallery&model=840
http://www.apple-history.com/noframes/body.php?pa
I remember this because Fall of '93 was when I got my 660AV. Still have that baby in my basement. Great machines.
K.
Sorry, my I wasn't intending to suggest getting poutine at McDo or Burger King. By "fast food" I meant places like La Belle Province or LaFleur's, or anyone of a billion independent casse-croute places that can be found in Quebec (or, as someone else mentioned elsewhere, off a chip wagon in Ottawa).
Was never that big a fan of poutine, but my Saturday nights at Foufounes Electriques were never complete without some all-dressed steamies (hot dogs) just after 3AM on Boul. St-Laurent. Those really hit the spot.
But poutine is fast food. You wouldn't go to a fancy restaurant in Paris (or elsewhere) and order burger & fries, would you?
It seems unusual to me that it seems so much internet work is being done in CS. Maybe California has more of a communications emphasis, but here at UIUC we do practically no web programming, yet this is supposed to be the 2nd best school for CS.
(networking & data communications) != (web programming)
K.
And today, I'm left contemplating whether I should change my default shell in Linux to tcsh. But that would mean to change lots of files:
/bin/sh
Just imagine, you donwload something nice, do "./configure" and - voila - syntax error.
Huh? configure scripts should have
#!
as its first line, so it really shouldn't be a problem. (/bin/sh is usually just a link to bash on Linux systems.)
K.
Broadcom isn't exactly the most open company. At one company I worked for, we were using some Broadcom chips and the datasheets we got from them (as PDF) had a watermark on each and every page that said "Confidential for {Name of Company I worked for}", as well as a password for each file (a different password for each file, no less).
:-)
Not that they are entirely alone. We also had hard copy of Intel datasheets for some Ethernet chips that had bright yellow covers that detailed who they had been given to, and what to do if you 'found' them (ie return them to Intel), etc. They also had the ominous warning of "DO NOT REPRODUCE". A fellow I worked with was working on the driver for one of these Intel devices, and was about to be married. I did jokingly ask him if his fiancee knew that he was under strict orders from Intel not to have children.
K.
Don't build a maginot line that a hacker can plow through and then discover that Paris has no more defenses.
The Germans didn't plow through the Maginot Line, they went around it, plowing through Belgium and the Netherlands.
K.
But the question is what % of readers of slashdot can actually read morse code or even binary?
I personally think this whole geek/binary thing is a bit silly. As someone who does works on a regular basis playing with bits (working on embedded systems, and most of that is low-level code like device drivers), I use hex all the time instead of binary. It's a lot easier to represent stuff in hex (8 digits instead of 32 for a 32-bit value), and it doesn't take long to learn how to read hex and "see" which bits are set or cleared.
K.
For those in a position to select one of these embedded processors, they already know all of this.
Umm, I believe this assumption is not a good one. Lots of people working in embedded systems believe some of these myths. This article is aimed at making sure everyone in the field is aware of these pitfalls. For example, I've seen lots of CPU selector charts specify Dhyrstone MIPS to indicate CPU horsepower.
K.
Back in the Fall of 1997, I remember getting a newsletter from the Motorola semiconductor group touting that they had just shipped their 1 or 2-billionth 6805 microcontroller (can't remember the number, couldn't find it on their web site). I would imagine they've shipped a few more in the 5.5 years since then.
I found three links in a row on the Rense website referring to the possibility of SARS being a man-made bioweapon. A lot of the information from the three links is the same, but each does contain additional information.
one
two
three
I don't have time to research all of the claims made in those links, but some things did stick out to me:
They keep quoting Nikolai Filatov as saying he thinks the virus is man-made because "there is no vaccine for this virus, its make-up is unclear, it has not been very widespread and the population is not immune to it." with no further explanation. That quote raises a few points for me.
I also would like more information about why the virus being a supposed "cocktail of measles and mumps" could never occur in nature. Again, I'm not saying what he says isn't possible, I just what to know on what basis this claim is made.
I'm not saying that what they are claiming isn't true. I don't know. I do know that if I was hearing a lot of other scientists agreeing with this, I would probably pay a lot more attention to it. It would be nice to have a rebuttal (or confirmation) from a respected virologist, instead of just information provided by a site (rense.com) that also includes stories about Ernst Zundel (holocaust denier) and UFOs.
The complexities of it also tend to suggest human manufactured.
I wouldn't use complexity as any sort of argument for a human's hand in this. If anything, I would argue that complexity would point away from an artificial source and towards a natural one.
For all our advances in understanding of molecular biology, we still know far less than we don't know, especially about protein structure and fuction. If we knew enough about that, then most diseases for which we have identified the genes involved would be cured by now. Sequencing genes is relatively easy, identifying what the gene does is harder, but figuring out exactly how the protein product of the gene actually works (and how a mutation affects that functioning) is by far the hardest.
Human intervention in creating a virus would most likely take the form of "let's take this gene from another virus or organism and put it in this other virus". Things like that aren't too hard to identify by DNA sequence analysis (relatively simple pattern matching, after all). I'm sure after they sequenced the DNA of the virus, they started comparing it to other known sequences. (Interesting side note - I actually had a class with one of the people who sequenced the virus DNA - he was taking a few qualifying courses before starting his grad studies in molecular biology, and I was finishing my undergrad in biochemistry. It was funny to see the name and recognize the face almost 12 years later.)
It's Logan's Run all over again folks.
Thanks. At least I now understand why that red LED in the palm of my hand keeps flashing.
pre-increment is usually slightly faster than post increment. I can't rememenber the details, I'm sorry, but it's something about not making an internal copy of the variable be incrementing. This can be material if you're trying to get every bit of performance out of a piece of code.
In C, pre- and post-increment doesn't make a difference. Likewise, when using plain integral types in C++ (int, etc), it still doesn't make a difference. Where is does make a difference is when you get into operator overloading in C++.
Pre-increment increments the object and then evaluates to the new value. Post-increment increments the object and then evaluates to the *OLD* value of the object.
Overloading the pre-increment value is pretty easy - do the operation and return the updated 'this' (by reference).
However, overloading the post-increment requires you to make a *copy* of the original object before incrementing it, so that you can return the original value, not the new one. Thus the body of the post-increment function would look something like:
type orig = *this;
++(*this);
return orig;
Thus, using the post-increment will lead to a copy-constructor being invoked. Since it doesn't hurt to use one form or the other if all you are doing is incrementing and nothing else, a lot of C++ programmers just use
++i;
in preference to
i++;
Of course, if the operators and constructors are all inlined functions and the optimizer is good, hopefully all of the extra code generated to make a copy of the un-needed copy of the object will be removed, anyway. But why take the chance?
K.
Having read this book some years back about the relatively early development of NT, I remember Cutler being very anti-Unix. It was the OS that VMS was compared & contrasted with, and is still the OS that NT is put up against.
The book made it sound like Cutler didn't think much of Unix, and I remember comments along the lines of him thinking Unix had been put together by a bunch of University hackers and wasn't that well designed (of course compared to the OSes he had helped developed). It is kind of interesting to consider that now in light of the directions things have gone with respect to Linux et al. since the book was published.
Nevertheless, the book was an interesting read and seemed much less 'rah-rah' and awe-struck than these two articles.
Think about it, that would be the most obnoxious feature ever.
How so? About the only time my stylus is more than a few feet away from my Palm is when I have left it somewhere and walked away or lent it to someone else and they walked away with it. Even in the second case, I would only loan it to someone who would use it for a few minutes and give it back (ie they shouldn't get up and walk away with it).
Anyone who frequently has their stylus separated from their PDA/cell/etc can just disable the warning by always leaving the stylus set to 'un-tethered' through a software setting.
I expect such a feature to be fully customizable through the software - in addition to being able to disable it, I would want to control what type of warnings (visual, audible (including volume)), how long it has to be out of range before the warning occurs, etc.
Actually, I think it does. There's really not much a designer can do about a stylus apart from tethering it to the PDA, but I think most would agree that a tether would suck. It's the only necessarily separate object, and bound to be lost. Seems like a smart thing to do, including multiples of an easily lost object...
One design suggestion: how about some form of electronic tether? Perhaps something like one of akin to an RFID tag in the stylus. The 'mother-device' (PDA, phone, what-have-you) could check for proximity at an certain interval (every few seconds?) and start to complain (beep, warning message) if the stylus gets out of range. Of course, there would need to be ways to 'un-tether' and 're-tether' the stylus (changing to a new one, lending yours to someone else, etc.) through the SW. I don't know if this is feasible yet (size, cost, etc), but it's just an idea.
If they taught you 68k assembly the way they taught me x86 assembly, then you have ENTIRELY missed the point.
:-)
I learned x86 assembly as part of a first year 'Introduction to Computer Organization' course, in which the lectures focussed on computer architecture, including things like instruction set architectures, micro-instructions, etc., and the labs were programming in x86 assembly. I found the two complemented each other nicely.
The point wasn't to teach you how to program a 68k or x86 processor in assembly language. It was to give you some insight into how a processor operates and how it is programmed at a lower level than code in C, C++, Pascal, or what have you.
For what it's worth, learning 68k assembly in school would have helped me a lot more than x86. I've had to read and write a lot more of the former than the latter in my professional career. Of course, learning any assembly language, even a crappy Intel instruction set, made it a lot easier to learn (and appreciate) a better designed instruction sets and processors like 68k and PowerPC.
Heck, here are some more examples. I remember a memory management assignment in an data structures & algorithms class where we were allocating 'memory' from an array of integers. Another assignment in the same class had us doing different sorting algorithms by hand. For compiler design, our compilers had to output assembly code for a fictitious processor. The point was learning the concepts, not being trained to do a specific job. And I also remember people in those classes who didn't get that.
See here.
Unless you consider US$39.95 free...
Database A is in the possession of the merchant. Database B is in the possession of the credit card company.
I'm not sure if the credit card company receives much more than the amount, date, merchant identification, and the credit card #. Lots of smaller stores just have credit card/debit card terminal that they just swipe the card and enter a total amount - only enough for the credit card company to know where, when, and how much, but not exactly what.
This is why lots of stores have introduced "loyalty" programs of some sort, each with a membership card or number. They give you some small perks (discounts on some products, reward points for total spending, etc), in exchange for tracking your spending habits at their stores.
In Canada, AirMiles (nothing to do with any airlines frequent flier program) does this for a group of merchants (including The Bay/Zellers and Shell). In this case, the merchants get an even better picture of these consumers... Unless you do what my mother and sister do: my mother uses my sister's AirMiles number to help her build up points more quickly. Of course AirMiles just ends up with the spending habits of a person who can shop at two Safeways in two different timezones at the same time. I guess they could separate the info based on location, until one visits the other...