Jesus christ people he is asking you how he should go about building an ultra-stable application in C++. He told you he *has* to build it in C++ because there are critical libraries and other components that aren't availible in C++. Telling him he shouldn't build it in C++ anyway just isn't helpfull.
I hate to break it to people but there *are* libraries, especially for types of scientific computing, that are only (reasonably) availible in C++ or sometimes FORTRAN. Not only would abandoning these libraries mean he would completely have to reinvent the wheel but also might cause serious compatibility problems not to mention a much greater ongoing maintenence responsibility (he can't just check his program to make sure things still work when someone fixes a library bug).
Moreover, the idea that because he is considering using CORBA, IPC or whatever else speed can't matter enough to require C/C++ is dead wrong. It is true that whatever *parts* of the process are done using these components may not require huge amounts of speed but this doesn't mean one of these components isn't doing something very processor heavy.
In particular what he says sounds like the situation in some areas of scientific computing. If one is writing a program to do some sort of simulation or similar math intensive operations speed can be *very* important in the critical parts of the code but (in some cases) transfering information to the GUI or other components need not be particularly speedy (increasing by an order of magnitude may make a small difference in overall runtime). Imagine a program that does some kind of weather, or nuclear detonation simulation. The cross-processor communication and the core simulation kernel need to be very fast but the GUI and data input components need not be particularly fast. Also it is my understanding that often the critical libraries in this area are often only availible (at least freely) with C/C++ or fortran bindings.
Anyway I think it is important to distingush several different goals, ultra-stability, minimal downtime, and minimal data/computation loss. For instance a climate simulation that may run on a supercomputer for months it is very important to have minimal data/computation loss (i.e. if something goes bad you don't lose months of very valuable supercomputer time) but you need not have ulta-stability or minimal downtime. As long as when any node crashes the simulation can easily be restarted without loss of data there is no problem. On the other hand if you are running a website like slashdot it is minimal downtime that is important it doesn't really matter if some of the web server processes are rebooted once in awhile. If, on the other hand, you are writing code to monitor a nuclear power plant it is ultra-stability that is important (though I can't at the moment think of something that requires distributed processing and ultra-stability but I'm probably just missing something).
So I think the answer depends on what sort of stability you want. If it is important that no individual *node* crashes (though the GUI/other non-core components can crash) then you should pursue the seperation you described above. I have to admit I'm not an expert here but the client-server model (like mysql, X etc.) seems to work well in this context. However, this depends alot on what sort of data you need to transfer. If you just need to send the core setup commands and get back mostly unstructured info (say a grid of tempratures or other simple datasets) then I would suggest sticking with one of the simpler abstractions and don't get lost in CORBA. On the other hand if you need to send back and forth real objects with significant structure then creating your own serialization system/bindings is just asking for bugs.
On the other hand if what you want is minimal data/computation loss, downtime, or any other property where it is the overall system you care about not a crash at any particular node then I suggest concentrating less on dividing any one node into comp
The things that he needs are probably things like mpi or scientific computation libraries. He didn't list these libraries because they are presumably part of the core functionality and thus are all part of the core (controller) component or aren't possible to componentize (no point in restarting if this part goes bad)
It isn't clear yet that they are trying to *securely* prevent loading unsigned drivers into the kernel. There might just be a config setting or other toggle that hackish users can flip to load unsigned code into the kernel.
In fact it would seem they would have to have such a toggle. Otherwise how are even commercial software companies supposed to develop this code? Not only would it be a pain to sign the driver every time you are testing the latest code changes it would require giving access to the signing keys to whoever compiles a kernel extension.
As an aside this scheme seems totally useless for the proposed purpose. The makers of malware are just going to steal a legitamate software developers secret key and sign their code with that. MS won't be able to anything because tons of people will be mad if windows update breaks their computer. However, I don't know whether to credit this to stupidity or malicousness (just want to make it difficult for normal people to use OSS kernel level code).
I wouldn't put it past someone to make this allegation just to get slashdot subscribers to their podcast.
I don't know these people though (but do like thier podcasts) so it would be hasty of my to accuse them. However, I'm not sure I would be above doing something like this so other people out there might not be too.
As far as I could tell the only evidence present that the vulnerability really was a backdoor was the fact that the message length needed to be set to *exactly* one in order for the vulnerability to work. Presumably the argument then runs that poor coding wouldn't generate such a specific effect so it must be a delibrately coded back door.
This, however, overlooks many other possibilities and, unless there is other evidence I am unaware of, suggests an ignorance of security vulnerabilities by those making the suggestion. Frequently security vulnerabilities result from data being interpreted in an incorrect fashion as a result of pointer munging or memory collisions. Often some perfectly innocent piece of data (like message length) will get used as an index into some table or mistakenly used in stead of the correct variable in some test and cause incorrect execution or privelege escalation of the user's code.
Even if there is reason to believe this isn't a simple code error like this there are many other explanations other than microsoft or an employees malevolence. For instance imagine this situation:
Initially Metafile execution is designed to execute code in the fashion of the vulnerability with no requirement on the header length. This is perfectly plausible if it was programmed by some new hire without much awareness of security. Hell, it could be a bug introduced to do some sort of debug or get something up and working fast which just got left in the codebase. I'm sure all of us have made a change to our code that screws over security just to do some testing and sometimes people forget about it or get fired.
In any case this security issue in the code base is there and some other parts of windows start relying on it. The security experts eventually notice the issue but by now other parts of windows will break if it gets fixed. Perhaps then the deciscion is made to partially patch the vulnerability but leave a special value for some fields which triggers the old behavior so as not to break the other parts of windows. If this is the case it would explain microsoft's recluctance to patch 95 and other old systems, because a patch would require rewriting some significant part of the system.
Perhaps microsoft even intended to fix the vulnerability but the blah-blah group asks the metafile group to leave in a workaround (the special values) so they can continue to work on the rest of their component. Maybe then the groups are late to the deadline and forget about that issue in their rush. Or perhaps by this time the group members who knew about the workaround have left and no one knows to go back and remove it. Or maybe this is fixed as part of some larger patch applied to the source tree and when it breaks the build late at night and someone calls the metafile team whoever answers doesn't realize its a security issue and backs out the change but forgets to tell the people who made it.
Whether or not I have the details right the point is clear. There are a hundred innocent ways for this sort of vulnerability to arise. It is silly to jump to the conclusion it is an intentional backdoor.
They might just use a different BIOS and not do anything additional to make windows not work. So no trusted computing type stuff to prevent you from running windows but you might need to hack your bios or trick windows or something.
Yes, in most cases the list comprehension works can work out (often better) than map and lambda. However, their are some examples using reduce (see discussion at lambda the ultimate). I don't know what the final verdict ended up being but clearly functional programming style is being discouraged.
The only explanation google turned up for this is because python is supposed to have one way to do things. While I don't necessarily want a perl this seems to clash with the culture which prefers no explicit attribute protections. I just don't like feeling pushed and told to do things differently just because I *like* the functional style.
Well I guess their is no reason to turn this into another argument over this issue. I think I have my answer. But I think if a language continues to push our people who prefer to do things in one style it is going to lose a lot of converts to other languages like ruby.
Finally do you really mean a general yield is going to be in python 2.5. I understood this was the one issue that had technical problems unless you went to stackless python. Are you sure it isn't planned for python 3000.
So a couple months ago I got really into python. I've programmed in both C++, a bit of perl, and LISP (as well as a hodgepodge of other languages) and was really attracted to the powerful combination of functional tools and object oriented design. I found generators, iterators and other advanced language features absolutely great and started to really like the language.
As I got a bit more into the language I started finding myself continually frustrated. Despite the "we're all adults" attitude about privacy and object protection it seemed Guido (guy in charge of python language) repeatedly made deciscions telling me that I shouldn't use features like co-routines, continuations or other powerful features except in limited circumstances (generators). I've even heard rumors about removing map (or was it apply) from the language. It wasn't that these features couldn't be implemented (stackless python did it) or they wouldn't be usefull (see ruby's use of coroutines) but as best I could tell Guido didn't like these functional or otherwise non-sequential features. Overall this lack of general functionality just made the language feel sorta unfinished and frustrating.
I've moved on to ruby since then which, while underneath is pretty different, seems to give me all the features of python plus those general features like co-routines and continuations.
Anyway this post might be a little off topic but I was wondering if there was any valid reason not to involve these powerfull features other than just personal taste. I can understand if some programmers coming from a procedural background might find these features confusing or harm code readability but is there any other reason? I love these sort of additions and I just can't figure out why, despite clear interest (stackless python, several PEPs) they aren't included in python to make it feel 'complete'.
The post here makes it out like there is some sort of unwholesome prejudice in favor of big companies and large orders. This just ignores the universal effect large customers and uniform market segments have.
What do you think makes unions so powerfull? Why do we have anti-monopoly laws which are enforced even when a company is shy of complete monopoly (e.g. controls 85% of the marketplace). Quite simply a large segment of the market that acts together has more power than a similarly or larger sized segment of the market which makes individual choices.
If Jim bob decides he needs feature A on his OS he might decide not to buy WinXP if it doesn't exist. However, if Jim, the IT manager at a fortune 500 company, has the same opinion MS might lose thousands of sales. Who do you think it makes more sense to go write code specifically for?
This issue is only magnified by two additional points. First is that the individual buyers *aren't* geeks so don't have a clue about what various features mean. So if corporate users aren't going to buy XP if it doesn't have that annoying messaging feature present and individual users aren't even going to know enough to think about it including it will make MS more money! Secondly many home users want the same OS as they have at work. FOCUSING ON IT DEPARTMENTS IS FOCUSING ON HOME SALES!!
Finally I would like to say I don't think this is a problem in the first place. Allowing that damn little messaging thing was just a mistake b/c MS didn't think that anyone would be on a real network except corporate users. If they had they just would have put in default options for a home config turning it off. In general as apple has shown with "OS X" you don't need to cripple a OS to make it good for the consumer. Rather you just need some sensible defaults so the corporate features and other powerfull options aren't security holes.
No, I'm not talking about google's site. Of course they can do what they want with that but they very clearly stated in the message that they wouldn't be changing or adding any crazy graphics to that.
I'm talking about whether adsense should include this type of stuff (it may already) but several people were bitching about this prospect.
I think whether or not their is any structural conflict depents a lot on the exact structure of the relationship. Since google and AOL aren't merging but google is only holding a stake in AOL this could be kept as a purely financial arrangement (lots of companies have random investments) which doesn't filter down to the actual people doing the work. Generally you don't want to be sharing technology and close access with companies you only own 5% of. Still the talk about indexing AOLs content makes one think that there is more to this than just a few contracts about keeping ad revenue and some stock changing hands.
In particular the choice of words made me suspect that somehow AOL content was being given *some* benefit. If nothing is different than before in terms of content indexing why not just say this instead of the weird roundabout bit about indexing AOL content like all other content. One (unlikely) possibility is that they could be helping AOL to optimize their layout for google search. A more plausible possibility (in my opinion) is that they are going to apply their relevance techniques to help AOL optimize the ads it places (e.g. analyze who clicks through aol content and help them figure out which keywords would be best). Additionally they may create a seperate search especially for AOL members, i.e., optimize the search AOL presents to its own users.
These are only speculation but I very much doubt that the temptation to screw up search will be very strong. Basically this structural conflicts of interest you talk about is just that google makes money if AOL does well. Other than this they have every motivation to just stick to the contracts. However, as google only owns 5% of AOL they only get 1/20 of every extra dollar of profit AOL makes back. So any tweak to their search engine to benefit AOL would have to be expected increase AOL's profit more that 20 times as much as it would hurt google's profit in order for their to be any temptation at all. Yet the credibility of a search engine is a key issue with users and google.com is the core of google. They have to realize that any tweaks to favor AOL will likely be noticed or leaked by disgruntled employees and lose them *tons* of visitors and hence money. So I really doubt their is much incentive to help AOL in the results at all.
Sure it would be more reassuring if google just did a search enginge and ads so we were sure they had no conflict of interest. However, even then they would have interests in making sure certain potential competitors *didn't* succeed. Moreover, in the real world google doesn't have this option. If they don't want to be beaten out by companies that have even more conflicts of interest they need to be willing to make strategic moves. While refusing to do anything of the kind may appear to be the high road in the short term if it just ultimately means google loses out and MS or some other company with tons of conflicts takes over it is really the worse option for us.
I think the posts above have already made a good case that there is nothing wrong with google giving others the opportunity to display graphical ads. These ads might be annoying but so are blink tags, frames and a lot of DHTML websites but no one is saying the people involved in the HTML/javascript standards should be held accountable if people want to make bad websites. Google's motto is "don't be evil" not "don't let other people create annoying websites".
In fact wouldn't a google refusal to allow image based ads through their website be exactly the same sort of portal content censorship that gets everyone here (including me) so mad. I know I find it absolutely infuriating and totally evil when I used yahoo and they censored me from saying bad shit about them (in particular complaining about my profile being censored) in my personals profile or mentioning other things which might offend someone. While not exactly similar choosing not to pass image ads through your ad system because you don't like them or think it is annoying if people use them in their website has the same kind of 'I know better than you' attitude. While I think it might be reasonable to draw the line at pop-up/pop-under ads because these ads don't just make your site annoying to use they in some sense take over the viewer's computer so they can't easily leave your site, e.g., pop-up ads are the ad equivalent of death threats or other content whose inherint harm makes it reasonable to take down.
Aside from stopping MS from getting AOL google gets a 5% stake in AOL. They are buying stock, that stock has value. At some point in the future they can sell that stock (probably not right away due to contract agreements) and get money back.
Google no more gave up 1 Billion dollars than you give up money when you put it in you 401k. Sure Google likely paid more than the AOL percent was worth in return for additional contractual assurances (will use Google ads, won't do blah with MS etc..) but not the whole 1 billion. Only the difference between the true value of that stake and the amount they paid.
If not I don't really see the issue. Not editing your own bio isn't some sort of absolute commandment or moral principle, it's just a guideline to prevent fights and unpleasent disputes. Often people are inclined to remove true statements or overestimate their own importance in their bios and it is alot easier to tell them they shouldn't be editing their own bio than have to argue with them and tell them they aren't as cool as they think they are.
If Wales was adding paragraphs praising himself, or if it is true that this other guy is a co-founder (rather than employee) then there is a problem. Otherwise what is the issue? So long as his edits ultimately further the accuracy of the encyclopedia that's great. The entire point of wikipedia is that you don't validate the editor but their edits.
There are always different rules that apply to the site manager/owner than the rest of the users. These are sometimes because the owner needs more freedom/control than the other users or in cases like this because you have to trust the owner no matter what. If Wales wants to skew wikipedia he has *way* more power to do this than any other user so you need to trust him anyway. The question is whether he is abusing that power and so far this doesn't seem to show that he is.
In other words I don't think it is reasonable to believe canibalization is currently happening. However, given the issues of fixed (yearly) cost (I'm sure there is a better term) it seems reasonable that selling mindstorms at prices only slightly higher than regular legos would still be far less profitable than selling regular legos. However, once down into this range the mindstorms would start competiting with the regular legos for normal consumers. If this was the only way to make mindstorms sell enough to justify further R&D they could be in a real bind.
Basically I'm imagining the market looks something like this. Right now we have a huge number of parents buying regular legos for their kids and a few older kids and adults buying mindstorms. While mindstorms sell for way more than their marginal cost their just aren't enough of them sold to make them very profitable. Most of the people who buy mindstorms still see them as a toy so wouldn't be willing to pay much more than $200 for them (demand would suddenly drop off). However, pretty much everyone who specifically wants programable toys is already buying them at the current price. Hence the only way lego could significantly increase the number of people purchasing mindstorms is by lowering the price until it enters the range of normal lego consumers, i.e., by pulling normal lego consumers up the ladder into mindstorms. Yet since running two production lines (or whatever) can be far more expensive than running one this might be a net loss for lego.
One thing the author does not seem to take into account is the fixed cost of creating machines, factories, etc.. to build any blocks or other items specific to mindstorms. Even if the RIS is selling for 3 times the price of similarly equiped sets if way less people are buying the RIS it may not be worth the cost of keeping the factory running and other fixed (yearly) costs to produce that product line. The same issues come into play with the cheap chinese product he compared to the lego product. Additionally quality, place of production and other factors can all combine to make it considerably more expensive.
Frankly I find the canibalization idea pretty hard to swallow. It just doesn't seem reasonable to believe that the same people using the RIS would otherwise be out there buying all the different specialized lego models. Most likely they would be the people out there buying the big boxes of assorted pieces if they were buying legos at all. The best explanations I can think of along these lines is that either LEGO was afraid of dilluting it's child friendly brand by marketing toys which might be too complex for some young children or that if feared connecting basic lego sales to something like mindstorms where more savy adult customers are involved might allow FischerTechnik to get a foot in the door. However, neither of these seem plausible.
Ultimately I suspect the economics of selling mindstorms were just more complicated than the author realizes. He never quotes actual mindstorms sales figures, only a positive press buzz, so it is quite posssible they simply never achieved wide enough adoption to make money and there are large costs he never even considers. Marketing, deals with stores for promotions and other costs may all play a role in lego's deciscion.
While I don't think we can really say what the whole story is without more data I think a more reasonable guess is something like this. Despite positive press buzz mindstorms simply don't sell enough to generate significant amounts of profit. While the development of mindstorms itself may be a sunk cost this means it simply isn't work lego's while to develop new addons, promote the product or otherwise devote further resources. Lego discontinued all mindstorm products other than the RIS because these other *mindstorm* products were canibalizing revenue from the RIS. Even though these other product lines may have themselves been profitable without the same sales as RIS they just wouldn't have as high a margin so if a reasonable fraction of people would buy a second RIS if they didn't have these other options lego might improve profitability by dropping these additional sets. If they don't think it is worth investing more money in the mindstorm line this has no real downside for them.
As for why lego doesn't simply adjust prices to make the mindstorms sufficently profitable to justify further investment I suspect things are a little more complicated than the author suggests. The demand curve is likely far from linear which dramatic drop offs in sales if they push the price much above $200 and beyond what most people consider to be in the 'toy' range. So raising the price much isn't really an option but this doesn't imply that lowering the price would have similarly dramatic increases in purchases (the elasticity is far from constant). Likely in order to make mindstorm sales high enough to be worth significant R&D money they would have to lower the price so considerably that then mindstorms would directly canabalize regular lego sales (if you can get the computer set for an extra $30 who wouldn't).
Almost every nerd I know (myself included) wastes more time trying to set up the machine 'just so' to make every task super conveinent and easy than they actually save. I suggest getting the machine in a minimally working configuration and only trying to save time when a task becomes really burdensome and repetitive. Even then I would think twice and ask how much time it really takes and how much time it would take to make it faster.
Of course that wouldn't be anywhere near as much fun. That's what you should do if you are really interested in saving time. If you just want to have the enjoyment of knowing your machine is optimally set up to do whatever it is you do then follow the other suggestions you find here.
If you had looked at my post hard enough you would have seen I said the LAME code was never used as *data*, i.e., over code never reads the area of memory the LAME code resides at. I said nothing about it not being executed.
Anyway I made no claim that Sony would be okay with you acting as described. Luckily Sony is not the court. Of course the courts aren't stupid so they aren't going to believe that your huge library of music is really being used and necessery for recognizing songs you come across. If you kept the music in some non-playable (without difficult extraction) form (maybe pre-processed to match against snippets) the situation might be different.
The question is not about the non-execution. I tend to agree this is not itself legally relevant. The question is whether using someone else's copyrighted work for the soul purpose of recognizing that work when it appears counts as fair use. The fact that it is not executed is only relevant insofar as it supports the idea that it is being only used to regonize the work.
Frankly I don't know, though I think there have been some cases about it. If you had some legal grounds for your conclusion I would love to hear them but it isn't the sort of thing one can just intuit without knowing anything about it.
Doubtful. As I understand it the basic principles of corporations and their legal status were already part of english common law at the time of the revolution and the US simply adopted them. I would be very curious though to hear when this difference of grammar got started. Did it develop as a US vs. UK difference or did it have the same source as most of US UK language differences, namely that the US adopted the cambridge grammar system and the UK the oxford system (or vice versa I can't remember)?
If this wasn't a cambridge oxford difference it could reflect a different social focus. That is whether one is primarily concerned about the corporation as an economic entity or as a collection of individuals. On the other hand it could just reflect something as minor as the inclination of the various countries to have single individuals, massive groups of shareholders or partnerships owning corporations.
As someone who commented above pointed out intel openly acknowledges performance can be hurt. I don't know what you mean about not being acceptable to notice this as I've seen this sort of issue mentioned in pretty much every article I've read on HT starting quite far back.
HT is just another chip technology like any other. It is only in the rarest circumstances that a new technology will be better/faster for everything. These things all have tradeoffs and the question is whether the benefits are enough to exceed the disadvantages.
I really think you are being a little unfair to intel. If you had evidence that it decreased performance for most systems even when the software was compiled taking HT into account then you might have a point. However, as it is this is no different than IBM touting its RISC technology or AMD talking about their SIMD capabilities. For each of these technologies you could find some code which would actually run slower. If you happen to be running code which makes heavy use of some hardware optimized string instructions a RISC system can actually make things worse not to mention a whole other host of issues. The SIMD capabilities of most x86 processors required switching the FPU state which took time as well.
It's only reasonable that companies want to publisize their newest fancy technology and they are hardly unsavory because they don't put the potential disadvantages centrally in their advertisements/PR material. When you go on a first date do you tell the girl about your loud snoring, how you cheated on your ex or other bad qualities about yourself. Of course not, one doesn't lie about these things but it is only natural to want to put the best face forward and it seems ridiculous to hold intel to a higher standard than an individual in these matters.
This sort of effect has been talked about for as long as I remember hearing about hyperthreading. It was common knowledge long before the chips came out that running two threads on the same cache can cause performance issues. One can see this with two chips sharing an L2 cache so why should it be a surprise here?
The real question is whether this issue can be optimized for. If the developers design their code with HT in mind will this still be a problem since the other thread may belong to another process or would properly optimized code be able to deal with his?
Most importantly is this a rare effect or a common one? Would it be rare or common if you optimize your programs for an HT machine?
So there is *never* a 'next januaruy' so long as you aren't in january? After all january is always at the start of a year so it is never in the current year. Or is it always 12 months from the day? What then if a month lands partially in this year and partially next?
If you mean what I think you mean aren't you just saying that next blah always means the first blah which will occur after today.
Slashdot Mirror
Jesus christ people he is asking you how he should go about building an ultra-stable application in C++. He told you he *has* to build it in C++ because there are critical libraries and other components that aren't availible in C++. Telling him he shouldn't build it in C++ anyway just isn't helpfull.
I hate to break it to people but there *are* libraries, especially for types of scientific computing, that are only (reasonably) availible in C++ or sometimes FORTRAN. Not only would abandoning these libraries mean he would completely have to reinvent the wheel but also might cause serious compatibility problems not to mention a much greater ongoing maintenence responsibility (he can't just check his program to make sure things still work when someone fixes a library bug).
Moreover, the idea that because he is considering using CORBA, IPC or whatever else speed can't matter enough to require C/C++ is dead wrong. It is true that whatever *parts* of the process are done using these components may not require huge amounts of speed but this doesn't mean one of these components isn't doing something very processor heavy.
In particular what he says sounds like the situation in some areas of scientific computing. If one is writing a program to do some sort of simulation or similar math intensive operations speed can be *very* important in the critical parts of the code but (in some cases) transfering information to the GUI or other components need not be particularly speedy (increasing by an order of magnitude may make a small difference in overall runtime). Imagine a program that does some kind of weather, or nuclear detonation simulation. The cross-processor communication and the core simulation kernel need to be very fast but the GUI and data input components need not be particularly fast. Also it is my understanding that often the critical libraries in this area are often only availible (at least freely) with C/C++ or fortran bindings.
Anyway I think it is important to distingush several different goals, ultra-stability, minimal downtime, and minimal data/computation loss. For instance a climate simulation that may run on a supercomputer for months it is very important to have minimal data/computation loss (i.e. if something goes bad you don't lose months of very valuable supercomputer time) but you need not have ulta-stability or minimal downtime. As long as when any node crashes the simulation can easily be restarted without loss of data there is no problem. On the other hand if you are running a website like slashdot it is minimal downtime that is important it doesn't really matter if some of the web server processes are rebooted once in awhile. If, on the other hand, you are writing code to monitor a nuclear power plant it is ultra-stability that is important (though I can't at the moment think of something that requires distributed processing and ultra-stability but I'm probably just missing something).
So I think the answer depends on what sort of stability you want. If it is important that no individual *node* crashes (though the GUI/other non-core components can crash) then you should pursue the seperation you described above. I have to admit I'm not an expert here but the client-server model (like mysql, X etc.) seems to work well in this context. However, this depends alot on what sort of data you need to transfer. If you just need to send the core setup commands and get back mostly unstructured info (say a grid of tempratures or other simple datasets) then I would suggest sticking with one of the simpler abstractions and don't get lost in CORBA. On the other hand if you need to send back and forth real objects with significant structure then creating your own serialization system/bindings is just asking for bugs.
On the other hand if what you want is minimal data/computation loss, downtime, or any other property where it is the overall system you care about not a crash at any particular node then I suggest concentrating less on dividing any one node into comp
The things that he needs are probably things like mpi or scientific computation libraries. He didn't list these libraries because they are presumably part of the core functionality and thus are all part of the core (controller) component or aren't possible to componentize (no point in restarting if this part goes bad)
It isn't clear yet that they are trying to *securely* prevent loading unsigned drivers into the kernel. There might just be a config setting or other toggle that hackish users can flip to load unsigned code into the kernel.
In fact it would seem they would have to have such a toggle. Otherwise how are even commercial software companies supposed to develop this code? Not only would it be a pain to sign the driver every time you are testing the latest code changes it would require giving access to the signing keys to whoever compiles a kernel extension.
As an aside this scheme seems totally useless for the proposed purpose. The makers of malware are just going to steal a legitamate software developers secret key and sign their code with that. MS won't be able to anything because tons of people will be mad if windows update breaks their computer. However, I don't know whether to credit this to stupidity or malicousness (just want to make it difficult for normal people to use OSS kernel level code).
What about the PPC emulation on the new intel macs?
I wouldn't put it past someone to make this allegation just to get slashdot subscribers to their podcast.
I don't know these people though (but do like thier podcasts) so it would be hasty of my to accuse them. However, I'm not sure I would be above doing something like this so other people out there might not be too.
As far as I could tell the only evidence present that the vulnerability really was a backdoor was the fact that the message length needed to be set to *exactly* one in order for the vulnerability to work. Presumably the argument then runs that poor coding wouldn't generate such a specific effect so it must be a delibrately coded back door.
This, however, overlooks many other possibilities and, unless there is other evidence I am unaware of, suggests an ignorance of security vulnerabilities by those making the suggestion. Frequently security vulnerabilities result from data being interpreted in an incorrect fashion as a result of pointer munging or memory collisions. Often some perfectly innocent piece of data (like message length) will get used as an index into some table or mistakenly used in stead of the correct variable in some test and cause incorrect execution or privelege escalation of the user's code.
Even if there is reason to believe this isn't a simple code error like this there are many other explanations other than microsoft or an employees malevolence. For instance imagine this situation:
Initially Metafile execution is designed to execute code in the fashion of the vulnerability with no requirement on the header length. This is perfectly plausible if it was programmed by some new hire without much awareness of security. Hell, it could be a bug introduced to do some sort of debug or get something up and working fast which just got left in the codebase. I'm sure all of us have made a change to our code that screws over security just to do some testing and sometimes people forget about it or get fired.
In any case this security issue in the code base is there and some other parts of windows start relying on it. The security experts eventually notice the issue but by now other parts of windows will break if it gets fixed. Perhaps then the deciscion is made to partially patch the vulnerability but leave a special value for some fields which triggers the old behavior so as not to break the other parts of windows. If this is the case it would explain microsoft's recluctance to patch 95 and other old systems, because a patch would require rewriting some significant part of the system.
Perhaps microsoft even intended to fix the vulnerability but the blah-blah group asks the metafile group to leave in a workaround (the special values) so they can continue to work on the rest of their component. Maybe then the groups are late to the deadline and forget about that issue in their rush. Or perhaps by this time the group members who knew about the workaround have left and no one knows to go back and remove it. Or maybe this is fixed as part of some larger patch applied to the source tree and when it breaks the build late at night and someone calls the metafile team whoever answers doesn't realize its a security issue and backs out the change but forgets to tell the people who made it.
Whether or not I have the details right the point is clear. There are a hundred innocent ways for this sort of vulnerability to arise. It is silly to jump to the conclusion it is an intentional backdoor.
They might just use a different BIOS and not do anything additional to make windows not work. So no trusted computing type stuff to prevent you from running windows but you might need to hack your bios or trick windows or something.
Just a guess.
Yes, in most cases the list comprehension works can work out (often better) than map and lambda. However, their are some examples using reduce (see discussion at lambda the ultimate). I don't know what the final verdict ended up being but clearly functional programming style is being discouraged.
The only explanation google turned up for this is because python is supposed to have one way to do things. While I don't necessarily want a perl this seems to clash with the culture which prefers no explicit attribute protections. I just don't like feeling pushed and told to do things differently just because I *like* the functional style.
Well I guess their is no reason to turn this into another argument over this issue. I think I have my answer. But I think if a language continues to push our people who prefer to do things in one style it is going to lose a lot of converts to other languages like ruby.
Finally do you really mean a general yield is going to be in python 2.5. I understood this was the one issue that had technical problems unless you went to stackless python. Are you sure it isn't planned for python 3000.
So a couple months ago I got really into python. I've programmed in both C++, a bit of perl, and LISP (as well as a hodgepodge of other languages) and was really attracted to the powerful combination of functional tools and object oriented design. I found generators, iterators and other advanced language features absolutely great and started to really like the language.
As I got a bit more into the language I started finding myself continually frustrated. Despite the "we're all adults" attitude about privacy and object protection it seemed Guido (guy in charge of python language) repeatedly made deciscions telling me that I shouldn't use features like co-routines, continuations or other powerful features except in limited circumstances (generators). I've even heard rumors about removing map (or was it apply) from the language. It wasn't that these features couldn't be implemented (stackless python did it) or they wouldn't be usefull (see ruby's use of coroutines) but as best I could tell Guido didn't like these functional or otherwise non-sequential features. Overall this lack of general functionality just made the language feel sorta unfinished and frustrating.
I've moved on to ruby since then which, while underneath is pretty different, seems to give me all the features of python plus those general features like co-routines and continuations.
Anyway this post might be a little off topic but I was wondering if there was any valid reason not to involve these powerfull features other than just personal taste. I can understand if some programmers coming from a procedural background might find these features confusing or harm code readability but is there any other reason? I love these sort of additions and I just can't figure out why, despite clear interest (stackless python, several PEPs) they aren't included in python to make it feel 'complete'.
The post here makes it out like there is some sort of unwholesome prejudice in favor of big companies and large orders. This just ignores the universal effect large customers and uniform market segments have.
What do you think makes unions so powerfull? Why do we have anti-monopoly laws which are enforced even when a company is shy of complete monopoly (e.g. controls 85% of the marketplace). Quite simply a large segment of the market that acts together has more power than a similarly or larger sized segment of the market which makes individual choices.
If Jim bob decides he needs feature A on his OS he might decide not to buy WinXP if it doesn't exist. However, if Jim, the IT manager at a fortune 500 company, has the same opinion MS might lose thousands of sales. Who do you think it makes more sense to go write code specifically for?
This issue is only magnified by two additional points. First is that the individual buyers *aren't* geeks so don't have a clue about what various features mean. So if corporate users aren't going to buy XP if it doesn't have that annoying messaging feature present and individual users aren't even going to know enough to think about it including it will make MS more money! Secondly many home users want the same OS as they have at work. FOCUSING ON IT DEPARTMENTS IS FOCUSING ON HOME SALES!!
Finally I would like to say I don't think this is a problem in the first place. Allowing that damn little messaging thing was just a mistake b/c MS didn't think that anyone would be on a real network except corporate users. If they had they just would have put in default options for a home config turning it off. In general as apple has shown with "OS X" you don't need to cripple a OS to make it good for the consumer. Rather you just need some sensible defaults so the corporate features and other powerfull options aren't security holes.
No, I'm not talking about google's site. Of course they can do what they want with that but they very clearly stated in the message that they wouldn't be changing or adding any crazy graphics to that.
I'm talking about whether adsense should include this type of stuff (it may already) but several people were bitching about this prospect.
I think whether or not their is any structural conflict depents a lot on the exact structure of the relationship. Since google and AOL aren't merging but google is only holding a stake in AOL this could be kept as a purely financial arrangement (lots of companies have random investments) which doesn't filter down to the actual people doing the work. Generally you don't want to be sharing technology and close access with companies you only own 5% of. Still the talk about indexing AOLs content makes one think that there is more to this than just a few contracts about keeping ad revenue and some stock changing hands.
In particular the choice of words made me suspect that somehow AOL content was being given *some* benefit. If nothing is different than before in terms of content indexing why not just say this instead of the weird roundabout bit about indexing AOL content like all other content. One (unlikely) possibility is that they could be helping AOL to optimize their layout for google search. A more plausible possibility (in my opinion) is that they are going to apply their relevance techniques to help AOL optimize the ads it places (e.g. analyze who clicks through aol content and help them figure out which keywords would be best). Additionally they may create a seperate search especially for AOL members, i.e., optimize the search AOL presents to its own users.
These are only speculation but I very much doubt that the temptation to screw up search will be very strong. Basically this structural conflicts of interest you talk about is just that google makes money if AOL does well. Other than this they have every motivation to just stick to the contracts. However, as google only owns 5% of AOL they only get 1/20 of every extra dollar of profit AOL makes back. So any tweak to their search engine to benefit AOL would have to be expected increase AOL's profit more that 20 times as much as it would hurt google's profit in order for their to be any temptation at all. Yet the credibility of a search engine is a key issue with users and google.com is the core of google. They have to realize that any tweaks to favor AOL will likely be noticed or leaked by disgruntled employees and lose them *tons* of visitors and hence money. So I really doubt their is much incentive to help AOL in the results at all.
Sure it would be more reassuring if google just did a search enginge and ads so we were sure they had no conflict of interest. However, even then they would have interests in making sure certain potential competitors *didn't* succeed. Moreover, in the real world google doesn't have this option. If they don't want to be beaten out by companies that have even more conflicts of interest they need to be willing to make strategic moves. While refusing to do anything of the kind may appear to be the high road in the short term if it just ultimately means google loses out and MS or some other company with tons of conflicts takes over it is really the worse option for us.
I think the posts above have already made a good case that there is nothing wrong with google giving others the opportunity to display graphical ads. These ads might be annoying but so are blink tags, frames and a lot of DHTML websites but no one is saying the people involved in the HTML/javascript standards should be held accountable if people want to make bad websites. Google's motto is "don't be evil" not "don't let other people create annoying websites".
In fact wouldn't a google refusal to allow image based ads through their website be exactly the same sort of portal content censorship that gets everyone here (including me) so mad. I know I find it absolutely infuriating and totally evil when I used yahoo and they censored me from saying bad shit about them (in particular complaining about my profile being censored) in my personals profile or mentioning other things which might offend someone. While not exactly similar choosing not to pass image ads through your ad system because you don't like them or think it is annoying if people use them in their website has the same kind of 'I know better than you' attitude. While I think it might be reasonable to draw the line at pop-up/pop-under ads because these ads don't just make your site annoying to use they in some sense take over the viewer's computer so they can't easily leave your site, e.g., pop-up ads are the ad equivalent of death threats or other content whose inherint harm makes it reasonable to take down.
Oops this wasn't meant to be a reply to the joke but to the chilren claiming google gave away money just to stop MS.
Aside from stopping MS from getting AOL google gets a 5% stake in AOL. They are buying stock, that stock has value. At some point in the future they can sell that stock (probably not right away due to contract agreements) and get money back.
Google no more gave up 1 Billion dollars than you give up money when you put it in you 401k. Sure Google likely paid more than the AOL percent was worth in return for additional contractual assurances (will use Google ads, won't do blah with MS etc..) but not the whole 1 billion. Only the difference between the true value of that stake and the amount they paid.
If not I don't really see the issue. Not editing your own bio isn't some sort of absolute commandment or moral principle, it's just a guideline to prevent fights and unpleasent disputes. Often people are inclined to remove true statements or overestimate their own importance in their bios and it is alot easier to tell them they shouldn't be editing their own bio than have to argue with them and tell them they aren't as cool as they think they are.
If Wales was adding paragraphs praising himself, or if it is true that this other guy is a co-founder (rather than employee) then there is a problem. Otherwise what is the issue? So long as his edits ultimately further the accuracy of the encyclopedia that's great. The entire point of wikipedia is that you don't validate the editor but their edits.
There are always different rules that apply to the site manager/owner than the rest of the users. These are sometimes because the owner needs more freedom/control than the other users or in cases like this because you have to trust the owner no matter what. If Wales wants to skew wikipedia he has *way* more power to do this than any other user so you need to trust him anyway. The question is whether he is abusing that power and so far this doesn't seem to show that he is.
In other words I don't think it is reasonable to believe canibalization is currently happening. However, given the issues of fixed (yearly) cost (I'm sure there is a better term) it seems reasonable that selling mindstorms at prices only slightly higher than regular legos would still be far less profitable than selling regular legos. However, once down into this range the mindstorms would start competiting with the regular legos for normal consumers. If this was the only way to make mindstorms sell enough to justify further R&D they could be in a real bind.
Basically I'm imagining the market looks something like this. Right now we have a huge number of parents buying regular legos for their kids and a few older kids and adults buying mindstorms. While mindstorms sell for way more than their marginal cost their just aren't enough of them sold to make them very profitable. Most of the people who buy mindstorms still see them as a toy so wouldn't be willing to pay much more than $200 for them (demand would suddenly drop off). However, pretty much everyone who specifically wants programable toys is already buying them at the current price. Hence the only way lego could significantly increase the number of people purchasing mindstorms is by lowering the price until it enters the range of normal lego consumers, i.e., by pulling normal lego consumers up the ladder into mindstorms. Yet since running two production lines (or whatever) can be far more expensive than running one this might be a net loss for lego.
Still it is just a guess.
One thing the author does not seem to take into account is the fixed cost of creating machines, factories, etc.. to build any blocks or other items specific to mindstorms. Even if the RIS is selling for 3 times the price of similarly equiped sets if way less people are buying the RIS it may not be worth the cost of keeping the factory running and other fixed (yearly) costs to produce that product line. The same issues come into play with the cheap chinese product he compared to the lego product. Additionally quality, place of production and other factors can all combine to make it considerably more expensive.
Frankly I find the canibalization idea pretty hard to swallow. It just doesn't seem reasonable to believe that the same people using the RIS would otherwise be out there buying all the different specialized lego models. Most likely they would be the people out there buying the big boxes of assorted pieces if they were buying legos at all. The best explanations I can think of along these lines is that either LEGO was afraid of dilluting it's child friendly brand by marketing toys which might be too complex for some young children or that if feared connecting basic lego sales to something like mindstorms where more savy adult customers are involved might allow FischerTechnik to get a foot in the door. However, neither of these seem plausible.
Ultimately I suspect the economics of selling mindstorms were just more complicated than the author realizes. He never quotes actual mindstorms sales figures, only a positive press buzz, so it is quite posssible they simply never achieved wide enough adoption to make money and there are large costs he never even considers. Marketing, deals with stores for promotions and other costs may all play a role in lego's deciscion.
While I don't think we can really say what the whole story is without more data I think a more reasonable guess is something like this. Despite positive press buzz mindstorms simply don't sell enough to generate significant amounts of profit. While the development of mindstorms itself may be a sunk cost this means it simply isn't work lego's while to develop new addons, promote the product or otherwise devote further resources. Lego discontinued all mindstorm products other than the RIS because these other *mindstorm* products were canibalizing revenue from the RIS. Even though these other product lines may have themselves been profitable without the same sales as RIS they just wouldn't have as high a margin so if a reasonable fraction of people would buy a second RIS if they didn't have these other options lego might improve profitability by dropping these additional sets. If they don't think it is worth investing more money in the mindstorm line this has no real downside for them.
As for why lego doesn't simply adjust prices to make the mindstorms sufficently profitable to justify further investment I suspect things are a little more complicated than the author suggests. The demand curve is likely far from linear which dramatic drop offs in sales if they push the price much above $200 and beyond what most people consider to be in the 'toy' range. So raising the price much isn't really an option but this doesn't imply that lowering the price would have similarly dramatic increases in purchases (the elasticity is far from constant). Likely in order to make mindstorm sales high enough to be worth significant R&D money they would have to lower the price so considerably that then mindstorms would directly canabalize regular lego sales (if you can get the computer set for an extra $30 who wouldn't).
Almost every nerd I know (myself included) wastes more time trying to set up the machine 'just so' to make every task super conveinent and easy than they actually save. I suggest getting the machine in a minimally working configuration and only trying to save time when a task becomes really burdensome and repetitive. Even then I would think twice and ask how much time it really takes and how much time it would take to make it faster.
Of course that wouldn't be anywhere near as much fun. That's what you should do if you are really interested in saving time. If you just want to have the enjoyment of knowing your machine is optimally set up to do whatever it is you do then follow the other suggestions you find here.
If you had looked at my post hard enough you would have seen I said the LAME code was never used as *data*, i.e., over code never reads the area of memory the LAME code resides at. I said nothing about it not being executed.
Anyway I made no claim that Sony would be okay with you acting as described. Luckily Sony is not the court. Of course the courts aren't stupid so they aren't going to believe that your huge library of music is really being used and necessery for recognizing songs you come across. If you kept the music in some non-playable (without difficult extraction) form (maybe pre-processed to match against snippets) the situation might be different.
The question is not about the non-execution. I tend to agree this is not itself legally relevant. The question is whether using someone else's copyrighted work for the soul purpose of recognizing that work when it appears counts as fair use. The fact that it is not executed is only relevant insofar as it supports the idea that it is being only used to regonize the work.
Frankly I don't know, though I think there have been some cases about it. If you had some legal grounds for your conclusion I would love to hear them but it isn't the sort of thing one can just intuit without knowing anything about it.
Doubtful. As I understand it the basic principles of corporations and their legal status were already part of english common law at the time of the revolution and the US simply adopted them. I would be very curious though to hear when this difference of grammar got started. Did it develop as a US vs. UK difference or did it have the same source as most of US UK language differences, namely that the US adopted the cambridge grammar system and the UK the oxford system (or vice versa I can't remember)?
If this wasn't a cambridge oxford difference it could reflect a different social focus. That is whether one is primarily concerned about the corporation as an economic entity or as a collection of individuals. On the other hand it could just reflect something as minor as the inclination of the various countries to have single individuals, massive groups of shareholders or partnerships owning corporations.
As someone who commented above pointed out intel openly acknowledges performance can be hurt. I don't know what you mean about not being acceptable to notice this as I've seen this sort of issue mentioned in pretty much every article I've read on HT starting quite far back.
HT is just another chip technology like any other. It is only in the rarest circumstances that a new technology will be better/faster for everything. These things all have tradeoffs and the question is whether the benefits are enough to exceed the disadvantages.
I really think you are being a little unfair to intel. If you had evidence that it decreased performance for most systems even when the software was compiled taking HT into account then you might have a point. However, as it is this is no different than IBM touting its RISC technology or AMD talking about their SIMD capabilities. For each of these technologies you could find some code which would actually run slower. If you happen to be running code which makes heavy use of some hardware optimized string instructions a RISC system can actually make things worse not to mention a whole other host of issues. The SIMD capabilities of most x86 processors required switching the FPU state which took time as well.
It's only reasonable that companies want to publisize their newest fancy technology and they are hardly unsavory because they don't put the potential disadvantages centrally in their advertisements/PR material. When you go on a first date do you tell the girl about your loud snoring, how you cheated on your ex or other bad qualities about yourself. Of course not, one doesn't lie about these things but it is only natural to want to put the best face forward and it seems ridiculous to hold intel to a higher standard than an individual in these matters.
This sort of effect has been talked about for as long as I remember hearing about hyperthreading. It was common knowledge long before the chips came out that running two threads on the same cache can cause performance issues. One can see this with two chips sharing an L2 cache so why should it be a surprise here?
The real question is whether this issue can be optimized for. If the developers design their code with HT in mind will this still be a problem since the other thread may belong to another process or would properly optimized code be able to deal with his?
Most importantly is this a rare effect or a common one? Would it be rare or common if you optimize your programs for an HT machine?
So there is *never* a 'next januaruy' so long as you aren't in january? After all january is always at the start of a year so it is never in the current year. Or is it always 12 months from the day? What then if a month lands partially in this year and partially next?
If you mean what I think you mean aren't you just saying that next blah always means the first blah which will occur after today.
Not from the south...typo