Yes, he's stupid for using 911, but is it only stupidity? Neither of us know. And, how stupid is he? Was this a test case for his larger-scale assault on 911 service and/or webTV users? We don't know that either. We may infer from the (limited) info in the article that this wasn't the case, that he was just out to annoy these 18 folks (who has 18 people they hate that much?!), but we still don't know what his intentions were, or what they would have evolved into had he not been caught.
Yeah, I didn't like your speeding example. Nor do I care much for your wildly imaginative and wholly unsupported clim that "something like 30% of the US population" are drunk drivers. That whole line of discussion is irrelevant anyway, IMHO.
The problem with this guy's crime is that it's pretty scalable. He could make a big problem for 911 with his bright idea. We don't know if he planned to expand his assult to a larger scale or not -- if he gave it even the slightest thought, then he's a terrorist. And, given that he clearly thought about it long enough to put that number in the script (911) instead of lots of others (such as international long distance, 1-900, etc.) that would have caused more hassle for the ostensible 18 "targets" and zero hassle for the public safety infreastructure, I'd say charging him on the assumption that he is a terrorist is the safe way to proceed. The courts will sort out whether it really was terrorism or not.
Nice try, but speeding is not necessarily public endangerment (that's a specific charge for speeding +30 MPH over the limit, I believe). Going faster than the posted limit when conditions allow (no cars on the road, good conditions, good car) seems far less dangerous to me than DDoS'ing the local emergency 911 response center.
Whether or not it was 27 calls or 2000, messing with 911 service is something we should (and obviously do) punish severely. Speeding, a few MPH over the limit, is more of a revenue generator for local municipalities than it is a serious public danger.
At least you admit it. But hey, does anyone else find it slimy that these "printer-friendly" links you provided only include part of the article? I thought the idea of "printer friendly" was to bring up a complete article, sans ads and extraneous graphics, so you can print. Once. To get it all.
How friendly is it to make me click seven pages one at a time, printing each, and having each one spill onto a fraction of the next when printed (depending on font size and marging, I suppose) so that I have to waste 10-11 sheets of paper and far too many clicks to get a 7-page article?
I'll tell you: it's not friendly at all. It's really annoying, and even though my proxy strips the ads off of every page anyway, I will not be bothered to click "next" 6 times after reading just a few paragraphs. It's just so obviously whoring that I can't play along as if the article is anything other than a blatant ad-impression generator.
Thanks for the link, but this new trend of not linking a link (or, ecen as you wisely did, including both a linked and an unlinked version) is confusing me.
You can set your/. preferences so that domains of all links are shown in brackets after every link, like this link to google, which would have [google.com] after it if you turn on this option (it's on by default even, I believe).
I understand that there are google and yahoo tricks occassionally used by trolls to redirect an apparent link to goatse (RIP) and tubgirl-type yuckiness, but it's not clear to me how forcing a copy&paste is any better at revealing a trick URL than just hovering one's mouse over the link to see the full URL before clicking.
In fact, if you just link, the uber-paranoid can right-click "copy link/URL" and then paste it in. How is not linking better?
This is intended neither as a troll or flamebait, and I apologize for interrupting the thread with this aside, but I'm really interested. Can anyone help me understand?
The dummy is strapped to the space station; whatever space debris does to the dummy, it'll do to the station itself. Let's hope it does nothing, as in no space debris hits the space station. Mmkay?;)
The redirector guy made profit because he was paid by the porn sites for the traffic. They don't care (or bother to check) how he gets the traffic to the site, they just count the impressions and pay the money (usually).
So, as with a lot of nefarious or nebulous web "businesses" (porn sites, spam, mortgage leads, etc.), the problem arises because of a disconnect in interest and accountability between the site owner who pays for impressions, and the scumbag who does scummy things to get them. To be clear: the guy mentioned in the article wasn't acutally running any porn sites himself, as far as I can tell, he was simply creating redirect sites that sent people who made typos to porn sites. The independently-run porn sites would pay him for each visitor he sent their way.
Of course, you're right in the long run that the porn sites will lose money on the deal (they pay scumbag, but his leads generate few or no closes). Maybe eventually it'll catch up to them and they stop paying for such useless leads (or at least to him in partuclar, until he changes his name or identity and does is all over again), but probably not. I remember the days when even reputable companies would pay a few bucks per 1000 pageviews, regardless of how you got them there, but that's long past, and the only sites still able to (promise) to pay such fees for visits are porn sites,
Yes, thats obvious, but not really the point. Traffic-monitoring systems certainly can't produce new roads, they can just be used to ensure a reasonably evenly-distributed load of traffic over existing roads.
If congestion is so bad that it exceeds the aggregate traffic-carrying capacity of all roads in an area (which seems to me would be very rare; likely only extreme catastrophes or emergencies, or in areas with very few roads), then you're still better off distributing the traffic over all possible routes instead of the shorter (and usually faster) one that everyone goes to without info telling them they shouldn't.
You're both wrong. It's Windows-driver writers, assuming you mean the set of persons who write drivers for the Windows operating system (I'm intentionally omitting any (R) or (TM) marks here since those are not grammatical elements rather legal marking and are thus outside the scope of this post.)
If you say Windows' driver writers you are referring to the set of persons who are owned by Windows and write drivers (which I believe is null set since Windows, being an operating system and not an individual or corporation, cannot own anyone. Technically, I suppose even MS can't legally own anyone, but one might use that colloquialism to refer to an MS employee and be understood.)
Windows modifies drivers, and Windows-driver work together to modify writers so the hyphen is required to form a sort of compound adjective. And, as has been correctly pointed out already, driver may be readilyt pluralized by appending a simple s; no apostraphe required.
For the coders among us here's an easier-to-remember explanation brought to you by the magic of parentheses:
This post brought to you by the letters F and U; the apostraphe had nothing to do with it.
Re:Slashdotted already - Google Cache
on
iPod Mini Autopsy
·
· Score: 1
And how, exactly, will copy & paste help you predict the destination URL's potential offensiveness any more reliably than simply hovering one's mouse pointer over the link to see the full URL before clicking?
Specifically, as the author eloquently states (IMHO):
The thing to notice here is how far behind we have left Aunt Tillie. Rule 1 of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong. The interface of the software should be all the documentation the user needs. You'd have lost the non-techie before the point in this troubleshooting sequence where a hacker like me even got fully engaged.
It's embarassing, even to me personally, but he's dead right. Not just for Aunt Tillie, but for you and me (can I get a humming of the Star Spangled Banner in the background now please, thanks) -- no one should have to stop to read man pages or html docs unless they are doing the most esoteric things with an app. Obviousness for everyone! We all know the basics -f -r, blah blah "standard" command line interface, and it works because (1) things act like they should and (2) we are experienced enough to know that "should" in the software/tool world expects a little more from us intellectually-wise than "should" in the normal day-to-day buy some bread rent a movie world.
The valid, relevant, even poignant point of this article, as I see it, is that it's not much work to go from where we are (which is comfy for us; a reasonable tradeoff 50/50 hassle for user/hassle for developer) to where we need to be to eat Microsoft's lunch (most hassle for developer, albeit 1-time hassle, and near-zero user hassle in most cases.)
We blow this stuff off because we want to make it workable for those smart enough to deserve to enjoy it then quickly move on to the Next Great Thing that Needs to be Made Now. We Peter principle ourselves out of making a real headache for MS, which is something we (ostensibly?) want.
Hmph. He said it well, and I for one am taking it to heart and thinking about how to make it better (with minimal effort, of course:) )
Isn't that an oxymoron these days, you know, like military intelligence or jumbo shrimp?
Re:Slashdotted already - Google Cache
on
iPod Mini Autopsy
·
· Score: 2, Informative
Screw the "drill", why don't you just make a link?
5 extra seconds for your trouble, vs 1000 x 5s for everyone; should be a no-brainer.
Re:Japanese developers allergic to worldwide launc
on
Sony Delays PSP To 2005
·
· Score: 2, Insightful
...and the mark-up. Japanese consumers generally tolerate much higher markups (it's for the good of the country, after all) than Americans and Europeans. One particularly relevant example from the many I've seen in Japan is the Sony PS2 -- it debuted in Japan for Yen49,500, about US$500 at the time. It wouldn't fly well in the US at that price point, and for those that money is no obstacle for, they can import one themselves. If you can get one -- they were out of stock everywhere even at $500 when I considered getting one in Akihabara.
- He doesn't mention the SCO lawsuit.
It was never brought up. There was no reason to.
Sure there is. It is, however unlikely to amount to anything, a slight pox on Linux right now, and it's an easy jab. Something I'd expect a MS lackey to use.
- He seems to think that Red Hat is Linux
"It's not so much Linux monolithic vs. Microsoft. But it's Novell SUSE with one price point, one set of functionality; Red Hat enterprise server with one price point, one set of functionality; and Windows server."
Thanks for reading the whole article.
I read it all, thanks. And you're welcome, I guess. Whatever. To requote: "Do you ride Microsoft's R&D wave, or do you ride this Red Hat Linux wave, knowing there's going to be some potential conflict with a vendor?" Which implies, to me at least, that he thinks and/or wants other to think that RedHat, Inc. (or LLC, or whatever they are) are doing all the development in Linux. Like the Kernal stood still and the only updates were being done by ditros upgrading utility versions.
- He compares his product to fast food
It's an analogy. They're not meant to be directly correlated to what's being said.
I know that pedant. I just think it's a lousy analogy, and not one I'd use for my product, unless of course my product were fast food.
I thought that at first, for a second, but the more I think about it the more I don't think this comment refers to SCO.
I think he means: you can count on Microsoft existing for a long time, and that MS technologies will continue to be ubiquitous. So you can get upgrades and support. The conflict would be because your vendor wasn't there any more, or wasn't supporting you anymore for whatever reason.
Then again, maybe it is just a oblique reference to SCO. I'm not sure, to be honest. Hmm.
He admits that desktop Linux use is increasing (but qualifies it with "in public-sector scenarios".)
He seems to think that Red Hat is Linux ("Do you ride Microsoft's R&D wave, or do you ride this Red Hat Linux wave, knowing there's going to be some potential conflict with a vendor?")
He compares his product to fast food ("So in some ways, we've got a McDonald's No. 5 super-size offering that costs $2.99 and someone just wants a Diet Coke that costs 99 cents. So do we cut the entire super-size No. 5 down to 98 cents, or do we try to find a way to just give somebody the Diet Coke if that's what they want?")
Some pretty good tough questions, with some not so direct answers. But still peculiar in the ways noted above. I'm surprised he gave that interview to begin with.
Because acknowledging AMD in a press release, even with a spin, is a public admission that AMD matters. Intel is still living under the fantasy (or at least projecting) that AMD does not matter, is not real competition, and will go away soon.
Intel mentioning AMD in a press release, to Intel, would be like McDonalds issuing a press release comparing their burgers to some local, one-store fast-food chain.
Keep reading down the comments at the linked site and you'll see an even more explicit gem from Linus:
Actually, I'm a bit disgusted at Intel for not even _mentioning_ AMD in
their documentation or their releases, so I'd almost be inclined to rename
the thing as "AMD64" just to give credit where credit is due. However,
it's just not worth the pain and confusion.
Any Intel people on this list: tell your managers to be f*cking ashamed of
themselves. Just because Intel didn't care about their customers and has
been playing with some other 64-bit architecture that nobody wanted to use
is no excuse for not giving credit to AMD for what they did with x86-64.
(I'm really happy Intel finally got with the program, but it's pretty
petty to not even mention AMD in the documentation and try to make it
look like it was all their idea).
I don't think anyone is surprised by this -- Intel would be nuts to mention AMD in any press release about anything unless it's incredibly negative toward AMD (which this definitely is not), and even then it would be ill-advised from a amrketing perspective.
If you RTFA you will realize that I'm not lying in the least when I say that, effectively, they ran out of flash-based "disk" space! They forgot to delete old files when updating the programs in the flash memory (which is mounted like a filesystem, or hard disk), and the OS was failing because it wanted to use that space. So it rebooted, and still had insufficient disk space, and rebooted again . . . lather rinse repeat. There was no signal because it was stuck in a reboot loop because they ran out of disk. Wow.
They fixed it by telling it to boot without using the flash (safe mode:) ), then used low-level (direct access) flash utilities to remove the old files. Reboot, mount, disk check / corruption repair, voila it works again.
We have a big 1TB NetApps server where I work, and we have so much disk space that people get lazy and don't delete files or archive old projects, then they get really confused when jobs fail, not thinking disk space until checking everything else first. But it happens, and it's usually surprisingly hard to debug (they check a lot of other things first, sometimes even upgrading tool versions!). It's really kinda funny, in an expensive and mildly embarassing way that the Spirit had the same problem.
I don't see why adding sensors and a microcontroller to a fully functional mechanical man wouldn't create an autonomous mechanical man
Because you can only make a robosapien do one, or some sequence of, 67 canned actions. You can't make new actions. It's just the 67, that's all forever, no more, no hope to expand.
Contrast with Aibo where every sensor and servo can be read/ignored/actuated to whatever degree you (or the stock programmers) can imagine.
That's what I mean by "micro scale control of movements".
I would hold that my analog thermostat, which has a sensor and reacts autonomously to enviromental factors to perform a useful mechcanical funtion is a robot, although lacking a microcontoller, or any electronic way of modifying its behaviour.
The robot/non-robot thing is a semantic aside. I'm sort of sorry for supporting the original poster on that -- "autonomous agent" is a better word for what I mean than is "robot".
But, your thermostat, generally expected to at most (1) turn on heat (2) turn off heat (3 turn on AC (4) turn off AC, is "robotic" in that it's automatic, and it does everything you'd expect a thermostat-robot to be able to do, controllable as finely as you like. An android robot, one might expect to be able to move each joint independently -- that's not the case here, as I have explained in several posts. This thing has 67 possible canned macro-level sequences it can act out. You can't just control the motors as you like and invent new behavior.
I take it you would disagree with me, and also hold that BEAM robots are not robots if they lack a microcontroler?
I take the robot-definition-changer support back. Really. It's a robot, for sure, it's just not an autonomous agent and there's no hope of making it one cheaply.
We may not be able to "code" directly against the RoboSapien, but that need not stop us from automating it.
Unless you're just interested in varying the combos/sequences of the 67 canned actions, or just want to control/program them from a different interface than the remote, yet is does.
A lot of posters in this thread, probably with some exposure to Aibo and the like, seem to have a hard time grasping how basically (fundamentally) different this is. I suppose I'm partially to blame for not coming up with a simple, easy to get example. To that end, try this:
Although the robosapien can move its right arm down as part of a dance, you cannot just make it move its right arm down without doing that dance. You can select "dance", or program "dance" to happen when the room lights come on, or after some other action via the remote, but to get that arm motion it must be doing "dance" as originally designed (no variations on "dance" allowed!)
In contrast, you can program any Aibo servo to move to any position exactly under any conditions -- it's your (the control program creator's) problem if it falls over doing so.
Sure it does. I didn't say it's hard to add a device to trigger or sequence the 67 possible motions of this thing. Heck, the remote does that. I just said you can't make or program new actions or intricate stimulus-response bahavior to it. It can only do 67 things, but it does them well, quickly, cheaply, and impressively.
No, the microcontroller used simply selects which canned action to replay. It's not programmable other than re-ordering these canned sequences. You most certainly cannot program it with whatever behaviour you want.
Here's a challenge -- it can dance, which includes bending it's left knee at one point. Amazingly, when bending the left knee, the rest of the robot bends accordingly to maintain balance. Try making it bend it's left knee at some other time during the dance and/or making it use another way to balance itself (arm extension vs. bending right ankle, for example). Sorry. (1) It can't -- the programmability on that fine a scale is not available and (2) it would fall over if it tried, because the control system doesn't know how to balance in anything other than the 67 pre-set conditions/sequences. You can make it dance, run, walk, turn, etc. but you cannot make it do a new dance.
A lot of the responses to my posts seem to be from those who erroneously assume I don't think this is cool. I do think this is cool. Very cool. I just don't think it will significantly affect the price, performance, or ubiquity of the more advanced, highly-programmable, and extensible digital robots out there. It's a different kind of system that trades programmability for inexpensive robustness.
I didn't say it wasn't interesting. One the contrary, it is an amazing control system, to repeat myself.
The real world can be analog and digital at the same time. It's red not blue. it's a sort of pinkish red. Is time discreet or continuos? What do you mean you do not know!
Time is continuous on the scale of interest to robotics -- human scale. No question.
Fixed, what is fixed? There are a lot of fixed values in the human body. In fact most of the body is based on very fixed processes. Feed back, is a very fixed response. The complexity comes with the sheer number of feedback systems working in parrallel. We cannot model this complexity with a pre-programmed system, but it may be possible to simulate the feedback and then set those loose to model the system.
Sure, if you're implementing the very-hard-to stabilize multiple simultaneous parallel interacting feedback loops. But that's not what this is. This thing does multiple sequential control systems. It's an important distinction theoretically and practically.
Have you _EVER_ worked with a digital robot, adding a new senosr is not easy? Adding a new response is not easy. In fact this is one of the main stumbling blocks of digital robots. Everytime you add a new sensor you have to explicity program for it. That means the robot is limited by the imagination/time of the designer.
Yes, I made a few based on 68HC11 microcontrollers in my EE undergrad work. It's technically challenging to add a new sensor and program/debug code to make it work in a digital system like that, especially if you don't know what you're doing. But it's infinitely easier to master than making a closed feedback loop control system be able to accept a new input and still be stable, much less actually do it.
In response to your last paragraph, take a look at beam robots. See how they can do tasks with a few components that complex digital robots cannot. See how they deal with component failures. Think about how this ties back to nature. See that tieing into a feedback circuit is easy, but ultimately unpredictable.
They each do pre-set things. Maybe several different ones, selectable in sequence, but the systems themselves are designed to be stable around a known point -- that's why they work -- there will never be any emergent behavior, or even cleverly-programmed unexpected behavior. It will always do what it does, however cool that may look.
Read Stephen Wolfram, Steve Grand and Mark Tilden. All three are showing that unpredictable complexity can be modeled by designing simple feedback systems and then letting them interfere with each other. Chaos theory is the underlying mathamatics.
Right, I didn't say it's not an interestig field with lots of cool stuff to discover. Maybe you're confusing me with the originator of this thread.
To cast aside this arena as just a cheap toy is to be blind to the sheer scope of the undertaking.
It is cheap. It is a toy. But I'm not casting it aside. I'm apt to buy one, in fact. I only noted that this technology is unlikely to decrease the cost of digital microcontroller-based robots and Aibo-like toys, except possibly by sheer competition and market force (at first), because it's fundamentally different technology.
Orville, Wilbour put down that paper plane it's just a toy.
An analog motor controller is usually a closed-loop feedback control system consisting or resistors, capacitors, inductors, and amplifying transistors. Which is not really the forte of ASICs. I'm not sure why you're under the impression there's an ASIC in the Robosapien -- I didn't see that anywhere, and I read every link I could find. I guess there could be, but that'd be overkill -- a simple PIC running a very simple state machine could handle this:
Using the ergonomic remote control, you can command Robosapien(TM) to perform up to 67 pre-programmed functions including pick-up, throw, high-five, whistle, dance and three different karate moves.
Robosapien(TM) is fully programmable. He can perform a programmed chain of commands in any combination of moves that you select. For example, you can create your own dance sequence or program him to walk straight, turn left and give your buddy a high five.
The cool thing about this isn't the complexity of the system, or it's ability to be as autonomous as even a Roomba, rather its lifelike motion accomplished by very fast, very cheap (but not at all flexible or extensible) analog closed-feedback loop control circuits.
Analog circuits, BTW, are much harder and more expensive to design than digital logic. Most cheap PICs and simple controllers include no such analog circuits (just A/D and/or D/A if you spend a bit more). Certainly not the highly custom and tuned ones needed here. ASICs also cost more for custom analog cores. Your ASIC vendor may give you a stock, commonly-used analog core for free (PLL, DLL, D/A, A/D, etc.) but you'll pay for custom layout, at least one test chip, and lots more per part to design your own RLC/amplfier circuit into an ASIC than just using the stock cellbase or gatearray digital logic.
And, without being even more expensive, the 1% accuracy you quote for passive component variations on cmos (the cheap) process is way low. More like 10-500%, especially for the relatively large (~kOhm, mH, and mF) R, L, and C values needed for control systems. It's easier to make really small R, L, and C's on cmos, but the accuracy is poor unless you pay a lot more than $80. Moreover, the amplifiers you need are too strong for cheap cmos processors -- why buy enough die for tens of thousands of tiny weak transisors optimized for on/off operation (which is the smallest feasible die to make these days) when you only need a few strong ones configured to amplify? Discrete would be cheaper and more precise/tunable in this case.
Slashdot Mirror
Yes, he's stupid for using 911, but is it only stupidity? Neither of us know. And, how stupid is he? Was this a test case for his larger-scale assault on 911 service and/or webTV users? We don't know that either. We may infer from the (limited) info in the article that this wasn't the case, that he was just out to annoy these 18 folks (who has 18 people they hate that much?!), but we still don't know what his intentions were, or what they would have evolved into had he not been caught.
Yeah, I didn't like your speeding example. Nor do I care much for your wildly imaginative and wholly unsupported clim that "something like 30% of the US population" are drunk drivers. That whole line of discussion is irrelevant anyway, IMHO.
The problem with this guy's crime is that it's pretty scalable. He could make a big problem for 911 with his bright idea. We don't know if he planned to expand his assult to a larger scale or not -- if he gave it even the slightest thought, then he's a terrorist. And, given that he clearly thought about it long enough to put that number in the script (911) instead of lots of others (such as international long distance, 1-900, etc.) that would have caused more hassle for the ostensible 18 "targets" and zero hassle for the public safety infreastructure, I'd say charging him on the assumption that he is a terrorist is the safe way to proceed. The courts will sort out whether it really was terrorism or not.
Nice try, but speeding is not necessarily public endangerment (that's a specific charge for speeding +30 MPH over the limit, I believe). Going faster than the posted limit when conditions allow (no cars on the road, good conditions, good car) seems far less dangerous to me than DDoS'ing the local emergency 911 response center.
Whether or not it was 27 calls or 2000, messing with 911 service is something we should (and obviously do) punish severely. Speeding, a few MPH over the limit, is more of a revenue generator for local municipalities than it is a serious public danger.
At least you admit it. But hey, does anyone else find it slimy that these "printer-friendly" links you provided only include part of the article? I thought the idea of "printer friendly" was to bring up a complete article, sans ads and extraneous graphics, so you can print. Once. To get it all.
How friendly is it to make me click seven pages one at a time, printing each, and having each one spill onto a fraction of the next when printed (depending on font size and marging, I suppose) so that I have to waste 10-11 sheets of paper and far too many clicks to get a 7-page article?
I'll tell you: it's not friendly at all. It's really annoying, and even though my proxy strips the ads off of every page anyway, I will not be bothered to click "next" 6 times after reading just a few paragraphs. It's just so obviously whoring that I can't play along as if the article is anything other than a blatant ad-impression generator.
Thanks for the link, but this new trend of not linking a link (or, ecen as you wisely did, including both a linked and an unlinked version) is confusing me.
/. preferences so that domains of all links are shown in brackets after every link, like this link to google, which would have [google.com] after it if you turn on this option (it's on by default even, I believe).
You can set your
I understand that there are google and yahoo tricks occassionally used by trolls to redirect an apparent link to goatse (RIP) and tubgirl-type yuckiness, but it's not clear to me how forcing a copy&paste is any better at revealing a trick URL than just hovering one's mouse over the link to see the full URL before clicking.
In fact, if you just link, the uber-paranoid can right-click "copy link/URL" and then paste it in. How is not linking better?
This is intended neither as a troll or flamebait, and I apologize for interrupting the thread with this aside, but I'm really interested. Can anyone help me understand?
The dummy is strapped to the space station; whatever space debris does to the dummy, it'll do to the station itself. Let's hope it does nothing, as in no space debris hits the space station. Mmkay? ;)
The redirector guy made profit because he was paid by the porn sites for the traffic. They don't care (or bother to check) how he gets the traffic to the site, they just count the impressions and pay the money (usually).
So, as with a lot of nefarious or nebulous web "businesses" (porn sites, spam, mortgage leads, etc.), the problem arises because of a disconnect in interest and accountability between the site owner who pays for impressions, and the scumbag who does scummy things to get them. To be clear: the guy mentioned in the article wasn't acutally running any porn sites himself, as far as I can tell, he was simply creating redirect sites that sent people who made typos to porn sites. The independently-run porn sites would pay him for each visitor he sent their way.
Of course, you're right in the long run that the porn sites will lose money on the deal (they pay scumbag, but his leads generate few or no closes). Maybe eventually it'll catch up to them and they stop paying for such useless leads (or at least to him in partuclar, until he changes his name or identity and does is all over again), but probably not. I remember the days when even reputable companies would pay a few bucks per 1000 pageviews, regardless of how you got them there, but that's long past, and the only sites still able to (promise) to pay such fees for visits are porn sites,
Yes, thats obvious, but not really the point. Traffic-monitoring systems certainly can't produce new roads, they can just be used to ensure a reasonably evenly-distributed load of traffic over existing roads.
If congestion is so bad that it exceeds the aggregate traffic-carrying capacity of all roads in an area (which seems to me would be very rare; likely only extreme catastrophes or emergencies, or in areas with very few roads), then you're still better off distributing the traffic over all possible routes instead of the shorter (and usually faster) one that everyone goes to without info telling them they shouldn't.
You're both wrong. It's Windows-driver writers, assuming you mean the set of persons who write drivers for the Windows operating system (I'm intentionally omitting any (R) or (TM) marks here since those are not grammatical elements rather legal marking and are thus outside the scope of this post.)
If you say Windows' driver writers you are referring to the set of persons who are owned by Windows and write drivers (which I believe is null set since Windows, being an operating system and not an individual or corporation, cannot own anyone. Technically, I suppose even MS can't legally own anyone, but one might use that colloquialism to refer to an MS employee and be understood.)
Windows modifies drivers, and Windows-driver work together to modify writers so the hyphen is required to form a sort of compound adjective. And, as has been correctly pointed out already, driver may be readilyt pluralized by appending a simple s; no apostraphe required.
For the coders among us here's an easier-to-remember explanation brought to you by the magic of parentheses:
Windows-driver writers == (Windows driver) writers
Windows' driver writers == Windows' (driver writers)
This post brought to you by the letters F and U; the apostraphe had nothing to do with it.
And how, exactly, will copy & paste help you predict the destination URL's potential offensiveness any more reliably than simply hovering one's mouse pointer over the link to see the full URL before clicking?
Specifically, as the author eloquently states (IMHO):
:) )
The thing to notice here is how far behind we have left Aunt Tillie. Rule 1 of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong. The interface of the software should be all the documentation the user needs. You'd have lost the non-techie before the point in this troubleshooting sequence where a hacker like me even got fully engaged.
It's embarassing, even to me personally, but he's dead right. Not just for Aunt Tillie, but for you and me (can I get a humming of the Star Spangled Banner in the background now please, thanks) -- no one should have to stop to read man pages or html docs unless they are doing the most esoteric things with an app. Obviousness for everyone! We all know the basics -f -r, blah blah "standard" command line interface, and it works because (1) things act like they should and (2) we are experienced enough to know that "should" in the software/tool world expects a little more from us intellectually-wise than "should" in the normal day-to-day buy some bread rent a movie world.
The valid, relevant, even poignant point of this article, as I see it, is that it's not much work to go from where we are (which is comfy for us; a reasonable tradeoff 50/50 hassle for user/hassle for developer) to where we need to be to eat Microsoft's lunch (most hassle for developer, albeit 1-time hassle, and near-zero user hassle in most cases.)
We blow this stuff off because we want to make it workable for those smart enough to deserve to enjoy it then quickly move on to the Next Great Thing that Needs to be Made Now. We Peter principle ourselves out of making a real headache for MS, which is something we (ostensibly?) want.
Hmph. He said it well, and I for one am taking it to heart and thinking about how to make it better (with minimal effort, of course
elegant legislation
Isn't that an oxymoron these days, you know, like military intelligence or jumbo shrimp?
Screw the "drill", why don't you just make a link?
5 extra seconds for your trouble, vs 1000 x 5s for everyone; should be a no-brainer.
...and the mark-up. Japanese consumers generally tolerate much higher markups (it's for the good of the country, after all) than Americans and Europeans. One particularly relevant example from the many I've seen in Japan is the Sony PS2 -- it debuted in Japan for Yen49,500, about US$500 at the time. It wouldn't fly well in the US at that price point, and for those that money is no obstacle for, they can import one themselves. If you can get one -- they were out of stock everywhere even at $500 when I considered getting one in Akihabara.
- He doesn't mention the SCO lawsuit.
It was never brought up. There was no reason to.
Sure there is. It is, however unlikely to amount to anything, a slight pox on Linux right now, and it's an easy jab. Something I'd expect a MS lackey to use.
- He seems to think that Red Hat is Linux
"It's not so much Linux monolithic vs. Microsoft. But it's Novell SUSE with one price point, one set of functionality; Red Hat enterprise server with one price point, one set of functionality; and Windows server." Thanks for reading the whole article.
I read it all, thanks. And you're welcome, I guess. Whatever. To requote: "Do you ride Microsoft's R&D wave, or do you ride this Red Hat Linux wave, knowing there's going to be some potential conflict with a vendor?" Which implies, to me at least, that he thinks and/or wants other to think that RedHat, Inc. (or LLC, or whatever they are) are doing all the development in Linux. Like the Kernal stood still and the only updates were being done by ditros upgrading utility versions.
- He compares his product to fast food
It's an analogy. They're not meant to be directly correlated to what's being said.
I know that pedant. I just think it's a lousy analogy, and not one I'd use for my product, unless of course my product were fast food.
I thought that at first, for a second, but the more I think about it the more I don't think this comment refers to SCO.
I think he means: you can count on Microsoft existing for a long time, and that MS technologies will continue to be ubiquitous. So you can get upgrades and support. The conflict would be because your vendor wasn't there any more, or wasn't supporting you anymore for whatever reason.
Then again, maybe it is just a oblique reference to SCO. I'm not sure, to be honest. Hmm.
Some pretty good tough questions, with some not so direct answers. But still peculiar in the ways noted above. I'm surprised he gave that interview to begin with.
Why?
Because acknowledging AMD in a press release, even with a spin, is a public admission that AMD matters. Intel is still living under the fantasy (or at least projecting) that AMD does not matter, is not real competition, and will go away soon.
Intel mentioning AMD in a press release, to Intel, would be like McDonalds issuing a press release comparing their burgers to some local, one-store fast-food chain.
Keep reading down the comments at the linked site and you'll see an even more explicit gem from Linus:
Actually, I'm a bit disgusted at Intel for not even _mentioning_ AMD in their documentation or their releases, so I'd almost be inclined to rename the thing as "AMD64" just to give credit where credit is due. However, it's just not worth the pain and confusion.
Any Intel people on this list: tell your managers to be f*cking ashamed of themselves. Just because Intel didn't care about their customers and has been playing with some other 64-bit architecture that nobody wanted to use is no excuse for not giving credit to AMD for what they did with x86-64.
(I'm really happy Intel finally got with the program, but it's pretty petty to not even mention AMD in the documentation and try to make it look like it was all their idea).
I don't think anyone is surprised by this -- Intel would be nuts to mention AMD in any press release about anything unless it's incredibly negative toward AMD (which this definitely is not), and even then it would be ill-advised from a amrketing perspective.
If you RTFA you will realize that I'm not lying in the least when I say that, effectively, they ran out of flash-based "disk" space! They forgot to delete old files when updating the programs in the flash memory (which is mounted like a filesystem, or hard disk), and the OS was failing because it wanted to use that space. So it rebooted, and still had insufficient disk space, and rebooted again . . . lather rinse repeat. There was no signal because it was stuck in a reboot loop because they ran out of disk. Wow.
:) ), then used low-level (direct access) flash utilities to remove the old files. Reboot, mount, disk check / corruption repair, voila it works again.
They fixed it by telling it to boot without using the flash (safe mode
We have a big 1TB NetApps server where I work, and we have so much disk space that people get lazy and don't delete files or archive old projects, then they get really confused when jobs fail, not thinking disk space until checking everything else first. But it happens, and it's usually surprisingly hard to debug (they check a lot of other things first, sometimes even upgrading tool versions!). It's really kinda funny, in an expensive and mildly embarassing way that the Spirit had the same problem.
I don't see why adding sensors and a microcontroller to a fully functional mechanical man wouldn't create an autonomous mechanical man
Because you can only make a robosapien do one, or some sequence of, 67 canned actions. You can't make new actions. It's just the 67, that's all forever, no more, no hope to expand.
Contrast with Aibo where every sensor and servo can be read/ignored/actuated to whatever degree you (or the stock programmers) can imagine.
That's what I mean by "micro scale control of movements".
I would hold that my analog thermostat, which has a sensor and reacts autonomously to enviromental factors to perform a useful mechcanical funtion is a robot, although lacking a microcontoller, or any electronic way of modifying its behaviour.
The robot/non-robot thing is a semantic aside. I'm sort of sorry for supporting the original poster on that -- "autonomous agent" is a better word for what I mean than is "robot".
But, your thermostat, generally expected to at most (1) turn on heat (2) turn off heat (3 turn on AC (4) turn off AC, is "robotic" in that it's automatic, and it does everything you'd expect a thermostat-robot to be able to do, controllable as finely as you like. An android robot, one might expect to be able to move each joint independently -- that's not the case here, as I have explained in several posts. This thing has 67 possible canned macro-level sequences it can act out. You can't just control the motors as you like and invent new behavior.
I take it you would disagree with me, and also hold that BEAM robots are not robots if they lack a microcontroler?
I take the robot-definition-changer support back. Really. It's a robot, for sure, it's just not an autonomous agent and there's no hope of making it one cheaply.
We may not be able to "code" directly against the RoboSapien, but that need not stop us from automating it.
Unless you're just interested in varying the combos/sequences of the 67 canned actions, or just want to control/program them from a different interface than the remote, yet is does.
A lot of posters in this thread, probably with some exposure to Aibo and the like, seem to have a hard time grasping how basically (fundamentally) different this is. I suppose I'm partially to blame for not coming up with a simple, easy to get example. To that end, try this:
Although the robosapien can move its right arm down as part of a dance, you cannot just make it move its right arm down without doing that dance. You can select "dance", or program "dance" to happen when the room lights come on, or after some other action via the remote, but to get that arm motion it must be doing "dance" as originally designed (no variations on "dance" allowed!)
In contrast, you can program any Aibo servo to move to any position exactly under any conditions -- it's your (the control program creator's) problem if it falls over doing so.
Am I getting more pithy yet?
Sure it does. I didn't say it's hard to add a device to trigger or sequence the 67 possible motions of this thing. Heck, the remote does that. I just said you can't make or program new actions or intricate stimulus-response bahavior to it. It can only do 67 things, but it does them well, quickly, cheaply, and impressively.
No, the microcontroller used simply selects which canned action to replay. It's not programmable other than re-ordering these canned sequences. You most certainly cannot program it with whatever behaviour you want.
Here's a challenge -- it can dance, which includes bending it's left knee at one point. Amazingly, when bending the left knee, the rest of the robot bends accordingly to maintain balance. Try making it bend it's left knee at some other time during the dance and/or making it use another way to balance itself (arm extension vs. bending right ankle, for example). Sorry. (1) It can't -- the programmability on that fine a scale is not available and (2) it would fall over if it tried, because the control system doesn't know how to balance in anything other than the 67 pre-set conditions/sequences. You can make it dance, run, walk, turn, etc. but you cannot make it do a new dance.
A lot of the responses to my posts seem to be from those who erroneously assume I don't think this is cool. I do think this is cool. Very cool. I just don't think it will significantly affect the price, performance, or ubiquity of the more advanced, highly-programmable, and extensible digital robots out there. It's a different kind of system that trades programmability for inexpensive robustness.
I didn't say it wasn't interesting. One the contrary, it is an amazing control system, to repeat myself.
The real world can be analog and digital at the same time. It's red not blue. it's a sort of pinkish red. Is time discreet or continuos? What do you mean you do not know!
Time is continuous on the scale of interest to robotics -- human scale. No question.
Fixed, what is fixed? There are a lot of fixed values in the human body. In fact most of the body is based on very fixed processes. Feed back, is a very fixed response. The complexity comes with the sheer number of feedback systems working in parrallel. We cannot model this complexity with a pre-programmed system, but it may be possible to simulate the feedback and then set those loose to model the system.
Sure, if you're implementing the very-hard-to stabilize multiple simultaneous parallel interacting feedback loops. But that's not what this is. This thing does multiple sequential control systems. It's an important distinction theoretically and practically.
Have you _EVER_ worked with a digital robot, adding a new senosr is not easy? Adding a new response is not easy. In fact this is one of the main stumbling blocks of digital robots. Everytime you add a new sensor you have to explicity program for it. That means the robot is limited by the imagination/time of the designer.
Yes, I made a few based on 68HC11 microcontrollers in my EE undergrad work. It's technically challenging to add a new sensor and program/debug code to make it work in a digital system like that, especially if you don't know what you're doing. But it's infinitely easier to master than making a closed feedback loop control system be able to accept a new input and still be stable, much less actually do it.
In response to your last paragraph, take a look at beam robots. See how they can do tasks with a few components that complex digital robots cannot. See how they deal with component failures. Think about how this ties back to nature. See that tieing into a feedback circuit is easy, but ultimately unpredictable.
They each do pre-set things. Maybe several different ones, selectable in sequence, but the systems themselves are designed to be stable around a known point -- that's why they work -- there will never be any emergent behavior, or even cleverly-programmed unexpected behavior. It will always do what it does, however cool that may look.
Read Stephen Wolfram, Steve Grand and Mark Tilden. All three are showing that unpredictable complexity can be modeled by designing simple feedback systems and then letting them interfere with each other. Chaos theory is the underlying mathamatics.
Right, I didn't say it's not an interestig field with lots of cool stuff to discover. Maybe you're confusing me with the originator of this thread.
To cast aside this arena as just a cheap toy is to be blind to the sheer scope of the undertaking.
It is cheap. It is a toy. But I'm not casting it aside. I'm apt to buy one, in fact. I only noted that this technology is unlikely to decrease the cost of digital microcontroller-based robots and Aibo-like toys, except possibly by sheer competition and market force (at first), because it's fundamentally different technology.
Orville, Wilbour put down that paper plane it's just a toy.
That's not nice.
An analog motor controller is usually a closed-loop feedback control system consisting or resistors, capacitors, inductors, and amplifying transistors. Which is not really the forte of ASICs. I'm not sure why you're under the impression there's an ASIC in the Robosapien -- I didn't see that anywhere, and I read every link I could find. I guess there could be, but that'd be overkill -- a simple PIC running a very simple state machine could handle this:
Using the ergonomic remote control, you can command Robosapien(TM) to perform up to 67 pre-programmed functions including pick-up, throw, high-five, whistle, dance and three different karate moves.
Robosapien(TM) is fully programmable. He can perform a programmed chain of commands in any combination of moves that you select. For example, you can create your own dance sequence or program him to walk straight, turn left and give your buddy a high five.
The cool thing about this isn't the complexity of the system, or it's ability to be as autonomous as even a Roomba, rather its lifelike motion accomplished by very fast, very cheap (but not at all flexible or extensible) analog closed-feedback loop control circuits.
Analog circuits, BTW, are much harder and more expensive to design than digital logic. Most cheap PICs and simple controllers include no such analog circuits (just A/D and/or D/A if you spend a bit more). Certainly not the highly custom and tuned ones needed here. ASICs also cost more for custom analog cores. Your ASIC vendor may give you a stock, commonly-used analog core for free (PLL, DLL, D/A, A/D, etc.) but you'll pay for custom layout, at least one test chip, and lots more per part to design your own RLC/amplfier circuit into an ASIC than just using the stock cellbase or gatearray digital logic.
And, without being even more expensive, the 1% accuracy you quote for passive component variations on cmos (the cheap) process is way low. More like 10-500%, especially for the relatively large (~kOhm, mH, and mF) R, L, and C values needed for control systems. It's easier to make really small R, L, and C's on cmos, but the accuracy is poor unless you pay a lot more than $80. Moreover, the amplifiers you need are too strong for cheap cmos processors -- why buy enough die for tens of thousands of tiny weak transisors optimized for on/off operation (which is the smallest feasible die to make these days) when you only need a few strong ones configured to amplify? Discrete would be cheaper and more precise/tunable in this case.