It's funny how today's PCs continue to take architectural queues from earlier mainframe and minicomputer designs.
Remember when your IBM mainframe had an array of special I/O processors? Well, the bus arbitrator on your motherboard looks suspiciously like one of those. And remember when disk arrays because "smart"? Well... just looks at the electronics on the average SATA IDE drive and you'll see what I mean. It manages the hardware, and you only talk to the drive's on-board controller, never to the drive itself.
And now this network controller. Pardon me, I mean network card.
Hmmm... if by "she" you mean the author of the opening post you would be wrong. She didn't *write* an interesting article, she *quoted* one and then linked to it. That's something different.
Generally speaking I don't recall seeing many journalistic pieces that are both well-researched and ungrammatical or improperly spelled. In my personal opinion, if someone uses sloppy spelling and ungrammatical speech they are likely to do sloppy research and use slipshod reasoning as well. Students, journalists, bloggers, and the "man in the street". I'm making allowances for Slashdot's terrible editing environment and fact that people will quickly type a response and continue reading, so I'm not bothered by simple spelling mistakes (besides I make them myself all the time). There are limits however. Failing to distinguish between "their", "they're" and "there", and between "loose" and "to lose" is different from making simple spelling mistakes. It indicates a poor command of language. Nothing to worry about if a Frenchman, a Chinese, or an Arab makes such mistakes, but worrisome if a Brit, an American, or an Australian makes them.
So I don't see much justification for the "It's more important what they have to say than whether they can spell" line of argument, but I do tend to see some justification for the "If their writing is sloppy, unclear, and contains lots of errors, they're probably stupid" school of thought. I'm fully aware that's probably an Elitist point of view, but there you go.
As the physicscentral.com article (first link of the opening post) notes, some rule-breaking (e.g. tailgating) increases the likelihood of large-scale pile-ups.
When a pileup happens, I think it negates the entire advantage gained by "lubricating" blocks of law-abiding vehicles. The study mentioned didn't look at the likelihood of collisions as a result of rude driving behavior, so it's premature to advocate rude driving behavior as a means to reduce time spent in congestion.
I think we can distinguish between two types of "smart" meters:
- (a) meters that let information flow *into* our house from the electricity company (like "supply is currently tight, minimize your usage"). To which we can either instruct our own appliances to respond like "Ok, if it's really tight now I'll wait 20 minutes", or empower the "smart" meter to tell an appliance "Appliance XXX, switch to standby until I tell you to restart".
- (b) meters that let information flow *out* of our house to the electricity company "this household is now drawing XXX watts and has the following list of appliances on with their current power consumption {list}". (E.g. [Appliance_name, nominal power rating, maximum power rating, current power rating]).
I think we can all agree that type "a" meters aren't objectional and may be worth serious consideration. They just allow us to optimize our domestic electricity use, which is especially useful if we have double-tariff meters.
I think we can also agree that we do not want type "b" meters. This type of meter lets the electricity company monitor what amount of power each household consumes at what times and then lets it (a) influence those appliances directly or (b) allow them to model our individual power consumption pattern - at micro-level.
I'm not the only one's weary of the huge privacy concern. Burglars for example will make sure they quickly get access to such "confidential" and "protected" information. It's just great to be able to monitor the whole city for patterns of absence, let alone have full-scale real-time checks of owner absence, don't you think?
While household appliances (especially airco's) may be capable of drawing a lot of current, that pales when compared to e.g. offices and industrial facilities. And those tend to switch on between 08:00 and 09:00 and tend to switch off again between 17:00 and 18:00. Therefore peak demand will be with us for some time.
That idea of electric cars buffering peak demand from household appliances is fine and dandy, but how many electric cars are there right now? And in 10 years? How many households will be able to "mask" their peak demand because the car battery is supplying up the current? And besides, that car will need to stay at home *plugged in* for the duration of the peak demand. And it will need to be recharged *before* you can drive it. So: my guess is that you won't be able to use it to damp out the morning peak demand anyway.
The long and the short of it is that I believe that peak demand for electricity will be around for a long time to come. And with it peak prices.
What this man did was to collect and submit evidence that players (a) become emotionally highly involved in the online roleplaying games they play, (b) let their emotions spill over outside the game, and (c) don't even display the maturity to overcome their more primal frustrations by realising that this player is in fact playing the game by the rules instead of by custom. The way it was *designed* to be played in the first place.
Who would have believed him if he had claimed, before submitting documented evidence, that on-line players would actually (a) get so upset in-game and (b) let it get to their collective heads and (c) blissfully ignore the way the game is set up?
Someone who plays roleplaying games on a regular basis probably would, but not the world at large and probably not social scientists either. It's the merit of his research that he exposed this strong impact of games on players' emotions.
It's also much more informative than anecdotal stories about this-or-that Chinese player killing another player for flogging his borrowed magical sword because it's systematic, controlled, and documented.
I'm afraid it also provides solid evidence that there may be valid grounds for *legislating* certain aspects of on-line gaming simply because these games have such an emotional impact. I'm not saying that legislation *must* be enacted, merely that online games aren't just... well... kidd's stuff. It also proves that grown-ups are a *lot* more childish than one might assume at first glance.
Let's hear it for management. Whilst much of "management" is honest (and necessary) work, the scope for idiocy is greater than anywhere else. And that's because much of management involves the wielding of power and authority. Challenging a management decision is never seen as an exercise in objective criticism, but always as a power struggle, and treated as such.
Whenever a management decisions will be visible to those who are not subject to the decision-maker's authority, "management" is often seen to drastically scale back the scope of what it first mandated as necessary, instated as "policy", and enforced. The downside is that climbdowns are rarely the result of a realization of "Oops... what we did was really stupid, so lets not do it anymore", but mostly "Oops... we're getting bad publicity on this one... time to do some managerial damage control". Stupidity remains unchallenged (unless it can be used by a manager to discredit a rival).
This example is also a salutary lesson for those who thought that Dilbert stories are all based in an imaginary world. As Scott Adams said: many of his examples come from real-life occurrences that he either witnessed himself or were emailed to him.
I expressly mentioned Matlab (and Octave and Scilab) in my post because they are so powerful when it comes to (numerical) computations. As a matter of fact, when I have to do linear algebra calculations, I think of such a language long before I turn to Fortran.
As other posters point out however, the prowess of languages like Matlab and Octave at linear algebra, differential equations, etc. comes from the fact that in such cases the interpreted language merely acts as the glue between successive calls to subroutine libraries (BLAS, LAPACK, FFT, etc.). The amount of work spent in Matlab (or Octave) mainly consists of setting up the library calls and storing the results. The hard work is done in the libraries.
Of course this is of no interest if you just want to get the calculations done. Octave etc. will get you the right results, and make them easy to inspect and process as well. Therefore, provided you can arrange your calculations so that the bulk of the work can be confined to a couple of library calls, by all means: use Matlab, Octave, or Scilab.
However... sometimes you need to carry out massively repetitive computations on data that is not easily expressed in terms of function calls to standard libraries. In other words: loops. When you code such loops in an interpreted language (like Matlab) the overhead of the interpreter is added to every iteration you do. To the detriment of your runtimes.
Now Matlab afficionadoes will contend at this point that you only need to configure loops as vectorized code to still get the speed benefits (because vectors are handled inside the libraries that Matlab etc. call). I agree that whilst sometimes loops can be so vectorized this by no means holds for all all of them. And even if the code can be vectorized, the process takes insight, effort, and concentration. On the other hand, coding an algorithm exactly the way you would do it by hand is a lot easier, and a lot more suited to the real world of non-programmers writing programs. What's needed in that case is a compiled language, not an interpreted one, which doesn't impose all kinds of overhead when you do loops.
Java proponents will rear at this and will proceed to wax eloquent about byte-code interpreters, JIT compilation, and lazy evaluation. Unfortunately Java is a very poor choice for numerical work. Mainly due to the way the floating-point stuff is implemented, and how the interpreter e.g. doesn't respect the flow-sequence of your code but feels free to substitute any expression you write with one that's algebraically (but not necessarily numerically) equivalent without ever telling you about it. This tends to disqualify Java from numerical and scientific calculations in favor of a language that allows the programmer more control over the way that expression evaluation is done.
Thus a simple compiled language is needed. Just about any third-generation compiled language will do. C or C++ for example will deliver the same kind of performance as Fortran. Pascal will do likewise. Ada is fine too.
However, as we all know, coding in C or C++ is not for those who are sloppy about implementation details. At best the code won't run at all. Even worse, the code may run and silently hand back nonsense. It takes time to learn how to program properly (and safely) in C and C++, which is something the average Chemistry or Physics student can ill afford. Even if he has the inclination to learn.
Pascal is great for clarity of expression in programming and maintainable programs. Unfortunately it's less well suited to writing reusable programs, and (barring non-standard extensions) its strict typing can play hob with resizeable arrays. And as soon as you go allow extensions, you lose compatibility. I can be quite confident that I can take my old standard FORTRAN-77 code and run it in Japan, Russia, France, and Brazil with no more than a recompile and get the same answers every time. Try that with manufacturer-specific add-
Lets face it: Fortran (even Fortran-90) might not be fashionable, but it's a lot simpler (and therefore quicker and easier to learn) than C++, much faster than Python, and it lends itself well to the implementation of massive calculations.
It's definitely not a language for amateurs in the sense of people who like to fiddle with the system, are interested in how the compiler works, or who just want to make gee-whizz web mashups. It's a language for people who don't care a rat's *ss about computers or programming, but who need to get their calculations done without wasting time on fiddling with pointers and who need reliable answers without being bitten by silent array-boundary overflows to boot. So Slashdot might not be the best place to ask for an opinion.
Besides, most of today's numerical libraries (BLAS, LAPACK, ATLAS, EISPACK, FFT) are written in Fortran. If you want to use them, you could do worse than learn Fortran.
True, it's not a language you'd want to do sophisticated datastructures in, or tree-searches or text-processing or payroll accounting or database manipulation. But especially chemists (and to a lesser extent physicists) have more call for numerical software than they have for non-numerical software.
So no. It's not at all ridiculous to teach Fortran as a first programming language to non-computer-science students. Alongside Matlab (or Octave or Scilab) it will do fine for chemists.
Even in a small company, there ought to be someone who's your manager. Have you talked to him? He ought to be on your side.
After all... you're looking after the company's hardware, the company's network, and the company's main equipment: the PCs. You enable the company's Human Resources to do their work. If people make your work difficult, then the company may have a problem. Flounting company guidelines on how to use computers is one of those things that may make a company loose a lot of money very quickly (e.g. if someone downloads a virus that wipes out a lot of work (or worse, gets sent to a client), if someone installs a bootleg version of a software package and the BSA comes calling).
Managers tend to be sensitive to that sort of thing. So how about having a talk with your manager and asking e.g. for backup in enforcing company policy? Once you have the authority to check up on someone and land them in trouble if they misbehave, respect will follow (unless you start abusing that authority of course).
I consider this an unusually thoughtful and perceptive move on part of the Government.
Fuel cells for cars are interesting, but hydrogen is over-hyped. Vehicles powered by batteries or capacitors are also emission-free (looking at the vehicle) and viable and promising. At least for distances less then 30 miles (which so happens to constitute more than 95% of all trips). So it's not a critical technology but it's a "nice to have" technology. Besides, like Chu says, hydrogen powered cars are looking at a long list of pesky and fairly fundamental problems which will take time to solve.
I applaud the decision to set up 8 smaller research establishments for 5 years instead of "one big one". Less photo opportunities perhaps, but (taking into account that they will work with local research centers and with industry) more chance of someone having a bright idea. And long enough to make it attractive for someone considering what field to specialize in to choose energy research.
I also like the decision to let the government stop looking for oil and gas. We have private industries that are quite adept at doing that, and (as Chu says) they have plenty of money to fund exploration. So pouring government funding into it is a dead waste. It's nice to be able to pick up the tab for costly and risky research for your oil-industry buddies, but that doesn't help the public.
I think this shows what can happen when you put an actual scientist in charge of research. And yes, Chu's freedom of action is severely limited by previous commitments, including the one to do research and produce material for nuclear weapons.
It all depends on your own take on your qualities.
Let's be blunt: if you're talented, a masters degree is easy and quick to do, and is probably your best bet regardless of any other considerations. Provided you complete it on schedule, it also proves that you are not just able to passively absorb and reproduce a lot of information, but also (depending a bit on what school you go to) that you are capable of independently applying the theory that's around in your area of expertise to a specific problem. That potentially makes you more valuable than someone with just a bachelor's degree, even if you have a little less on-the-job coding experience.
Unless what your prospective employer needs (or thinks he needs, or rather what his HR department thinks he needs) are straight-up coders who work hard and don't ask questions. In that case a BSc with more coding experience will be preferred.
In order to advance in the field you'll need to build a resume with successfully completed projects, in which it must be clear what *you* did (as opposed to the team you worked in). Writing a Master's thesis gives you such a project, which you'll have to do all by yourself (not counting all the advice and supervision you'll get). The point is that a Master's course is designed to allow you to shine, while work-experience is not. If you are really talented, you can show that in your thesis. What you will get in a workplace is a lot of simple tasks which, if completed in time and to-spec show that you're a solid production worker who may be ready for some more difficult assignments. In addition, if you're not the shiny type, your Masters work will still be a solid achievement.
If you think it would be hard to go on, then getting into the workplace is probably best. However, unless you show outstanding talent and/or managerial aptitude, your BSc degree will more likely slot you in a career as a coder than as a designer of software.
Last but not least. I don't want to scare you, but low-added-value work like pure (low-level) coding can easily be outsourced. To India for example. More complicated work, and especially work that involves a little thought and local knowledge is less easy to outsource.
I totally agree. Most "textbooks" on "Calculus" I've seen in the US seem to have been produced by people who are paid by the book's weight. They are full of are useless drivel that doesn't concern the actual mathematics, poor stabs at tutorial, and an extravagantly wasteful layout.
A book based on the "lecture notes" principle which also tries to use the available space can typically cover the same subject matter in a clear and concise manner in a quarter of the size and weight.
That would be something Open Source textbooks can address.
I have only one plea: don't make e-books. E-books on laptops aren't as easy on the eyes as even poorly typeset hardcopies.
Seriously, Microsoft has a huge cash-cow to protect in MS Office. And the first layer of defense is lock-in. If MS Office were truly inter-operable, then that would remove an enormous barrier against the introduction of Open Office.
Clearly Microsoft's best interests are served by denying their customers interoperability.
That's what drives Microsoft's policy: cash. Everything else is PR. Which is duly born out by their actions.
Several others already noted that botnet admins and designers might use the insights described in the paper to shore up their C&C communication. That's a minus, but a small one.
First of all, the whole exercise was cut short because the botnet admins updated the Mebroot toolkit, causing the researchers to loose contact. That happened before publication, ok? Secondly it shows that the easiest way to protect your botnet is to update Mebroot once a week (or sooner), and savvy botnet admins already knew that.
The big plus is that this research unequivocally points out MS Windows users' ability to write to the MBR and to modify executables as the main strategic access point. The general public didn't know that before. Now it does and it might decide that this is something that must be addressed. Either by switching to Linux or by more careful login management or by pounding the desk in Redmond and demanding a fix. Nothing else could have done that.
In addition it highlights the crucial importance of ISPs and registrars to respond immediately (and intelligently) to complaints of abuse. As the researchers point out, there is scope for streamlining and actually *using* existing procedures to terminate a registrar's accreditation. There may also be scope for legislation here in compelling any ISP or registrar to maintain a certain minimum capability for investigating abuse, and for instituting a legally binding maximum timespan between complaint and investigation. I would personally favour legislation to force those registrars and ISPs who do not have that capability out of business (or compel them to be taken over) within a year or so. That's something that would have been impossible to justify without this research.
So in short, the small disadvantage of alerting botnet admins to a vulnerability is far outweighed by the intelligence gathered. Intelligence that *must* be made public before it can be acted upon due to institutional torpor, stupidity, or tardiness.
First I'd like to express my admiration and gratitude for the researchers who pulled this one off, and the poster. This is truly illuminating stuff which (to my knowledge) provides the first solid and high-quality information on botnets in the public domain.
It's quite probable that this information (and particularly the techniques used to hijack the botnets) are also new and valuable to law-enforcement agencies. Such agencies tend to be desperately short of intelligence (both kinds), under-equipped to do research, and usually operate in a purely reactive way ("show us the bodies and we'll investigate").
And yes, I think that the researchers did fine by hijacking a botnet in the first place and secondly by not destroying it but instead contacting law-enforcement agencies. Researchers are neither law enforcement officers nor sysadmins for the infected systems. They have their own work to do (which law-enforcement agencies could not or would not do, or the Torpig botnet would have been cleaned up long ago).
It is interesting to note that *all* of the infected machines seem to be MS Windows based. Even though many of the targeted clients (Firefox, Skype) also run on Linux machines. If I had to guess I'd say that under Linux the need to have root access to either modify the MBR or to write downloaded malware code to the targeted executables on disk provides an effective barrier to infection (provided you don't surf the net with root privileges of course).
Unfortunately the publication of this sort of research may lead botnet administrators and designers to address the authentification weakness the researchers exploited. Ah well, such is life.
First of all, the media outrage which puts the blame for the recent mishaps on those who developed quantitative and statistical methods is pure and utter nonsense. The mathematical and statistical apparatus used are all correct. There is no question of untrue theorems being used or calculations being in error, there is the problem of true theorems being abused and unwarranted assumptions being entertained.
The problem is with improper use by those who use the (admittedly) sharp tools provides by quantitative financial modelers. One might intuitively expect bankers who are being paid six to seven-figure salaries to be able to see through and beyond financial models based only on statistical correlations, but alas, another hope dashed. Apparently the capacity for independent thought is not for sale even at those salary levels.
In the case of David Li, his copula is merely a convenient and computationally tractable way of doing calculations with multivariate Gaussian distributions. The problem is that the covariance matrix that describes the correlation of risks was calibrated on the *past* 10 years. Which is just fine if your multi-variate time-series is stationary. But misleading if there is e.g. a sudden regime change in your time-series.
Now the past 10 years were years of growth, wealth, and plenty of borrowing and the US of A are a rich country and its citizens can borrow an awful lot before there is any problem.
As a result all the banks saw a _low_ correlation between person X being unable to service his mortgage and person Y being able to service his mortgage. Therefore the road to financial safety for mortgage lenders was: make your portfolio big and make it varied. As big as possible and as varied as possible. And then make it even bigger. Because the Law of Large Numbers guarantees that the probability that large numbers of your clients will be unable to pay is quite small.How small? Well... you can calculate that to a nicety using 10 years worth of financial data. And you can budget for that. Great huh? The only thing you need to assume is that next year will be just like the past 10 years.
Any bank manager who wasn't prepared to sail as close to the wind as the financial models indicate was possible was sacked by his boss for not being result-oriented enough, which is a fairly broad hint for the remainder.
Unfortunately the correlation matrix, on which all those risk calculations hinge, is not a constant. It may change if massive numbers of borrowers suddenly hit their collective borrowing limits. When *that* happens, the probability of person X being unable to service his mortgage suddenly becomes a reasonably accurate predictor of person Y not being able to pay up in time. And the amount of risk you run with your huge mortgage portfolio suddenly increases dramatically. Which is exactly what happened.
Suddenly all the correlations went up, and banks found themselves sitting on enormous amounts of mortgage-backed loans which they couldn't even assess the risk of because they didn't really know the new correlation matrix.
This had two effects: first of all no bank would be happy to lend to another anymore because if it was hard to assess one's own risk position, it was impossible to assess that of another bank. So lending to any other bank was basically taking an unknown risk. Which they either refused to do (if they were short of cash themselves) or which they charged much higher rates for.
That was the birth of the liquidity crisis.
The second effect was the use of "slicing" the mortgage portfolio. That works as follows. You take a mortgage portfolio and you (hypothetically) sort its elements by probability of defaulting. Then you package the 10% highest risks as a new investment product. And then you sell it. You (honestly) tell your clients that it's high risk (and you tell them how high the risk is), but you offer a commensurate yield. Repeat that for the next 10% and so forth. In principle this is a fine idea which make
We have an extensive and poorly secured (as no un-passworded systems, vulnerable dictionary-based passwords, no system auditing, almost no network auditing) IT infrastructure, we have loads of national and international computer burglars banging away at it, we have a lot of people who know something about IT looking for a job, and we have a government looking for sensible ways to spend money so as to alleviate the recession.
Am I alone in thinking that it would be money well spent to set up 3 or so military schools in the US specifically to train network administrators? Students to enlist for the duration of their training (basic raining plus 2 years specialist training), subsequently 5 years of operational service as a sergeant. Graduates of this course to be unconditionally qualified for all basic network security and operation anywhere in the government (from local to federal).
It helps protect both our civillian and our military IT infrastructure, it builds a reservoir of people who know how to secure and operate a computer network for any government agency to draw from, and it provides jobs.
There's a really simple test about the desirability of private companies being allowed to put such stuff into orbit and then control it.
Just ask yourself if you'd be comfortable with the company controlling these orbital beamers being Chinese.
If you aren't, then it's a given that other countries will feel the same about US companies being in this position. And perhaps it good to bear in mind that the Chinese will probably have the money, the technology (or the spy-craft, which amounts to the same thing), and the will to replicate any such stuff within 10 years or so.
This sort of technology has such a (potential) impact on Earth itself that there are many legitimate stakeholders besides those of the US. As I see it, if we go about it with a "finders keepers" and "whoever has control has the right" mentality, that will come back to haunt us within 20 years.
Therefore I think it's probably a good idea to turn to the UN and legislate and regulate this sort of thing (i.e. orbital satellites beaming back industrial amounts of energy back to earth and trying to squelch hurricanes) before it happens. And for preference to have some sort of mechanism that makes certain that one country can't turn its deserts into a bread basket or its permafrost into a garden by e.g. disrupting the weather elsewhere. And to prepare some kind of enforcement (anything from communication cutouts to override codes to lasers to EMPs or missiles).
If we're quick about it, we can probably shape this regulation to suit us and any other reasonable party.
And all the relevant details will be in the "but".
When you consider the buts, you also discover that the question really isn't "Can rail work in the land where the car is king?", in the sense of "can train compete against car?" because the answer is a simple "No". Population density in any area that features large acres of suburbia is too low for the train to be a meaningful competitor for the car. Simply because the US have been grown that way for about a century. There aren't going to be any trains for commuters from the suburbs to the central business district, or even from the suburbs to the industrial areas.
The question is rather: "Can we find corridors in which the train will be competitive with both the car and the airplane". And the answer to this question is: "Yes, certainly.". The trick is to find heavily traveled routes that currently have a moderate to poor level of service. For example the Boston - New York City - Washington DC corridor would be well suited for a high-speed train that can travel in, say, 3 hours from Central Boston to Central Washington and which will also stop at Logan Intl., La Guardia, and RR Intl. Being able to reach both the airport and the city center will be crucial. The city centers because that's where most people need to go anyway, and the airports because they allow the train to provide access and egress to the air transport network.
The interesting thin is that a good train connection can be both quicker than air, bus, and car. Air because a train link can (if done right) dispense with time-loss due to check-in and the constant juggling for departure slots, boarding, and taxiing that's inherent in air travel. Buses and cars because both cars and buses are will be affected by congestion, and because of the speed limit on the highways.
It's possible to build a successful rail link in that corridor, but it will either take about 10 years to build because of all hard infrastructural problems (read acquisition of land and demolition of anything that's in the way of access to the city center and the airport) that need to be solved to get to the desirable areas (city centers, airports) or it will not connect to those vital points. If the envisioned rail service doesn't connect to the city centers and the airports, it will offer a service to take people from where they aren't to where they don't want to go.
So, yes, it's possible to build a successful rail link, but it's much easier to build one that's an absolute disaster. Financially, politically, and transport-wise. So don't get your hopes up too far.
Slashdot Mirror
Yes, you're right. Sorry, I'll take better care next time. I don't mind being corrected because spelling mistakes like this look stupid.
Remember when your IBM mainframe had an array of special I/O processors? Well, the bus arbitrator on your motherboard looks suspiciously like one of those. And remember when disk arrays because "smart"? Well ... just looks at the electronics on the average SATA IDE drive and you'll see what I mean. It manages the hardware, and you only talk to the drive's on-board controller, never to the drive itself.
And now this network controller. Pardon me, I mean network card.
Generally speaking I don't recall seeing many journalistic pieces that are both well-researched and ungrammatical or improperly spelled. In my personal opinion, if someone uses sloppy spelling and ungrammatical speech they are likely to do sloppy research and use slipshod reasoning as well. Students, journalists, bloggers, and the "man in the street". I'm making allowances for Slashdot's terrible editing environment and fact that people will quickly type a response and continue reading, so I'm not bothered by simple spelling mistakes (besides I make them myself all the time). There are limits however. Failing to distinguish between "their", "they're" and "there", and between "loose" and "to lose" is different from making simple spelling mistakes. It indicates a poor command of language. Nothing to worry about if a Frenchman, a Chinese, or an Arab makes such mistakes, but worrisome if a Brit, an American, or an Australian makes them.
So I don't see much justification for the "It's more important what they have to say than whether they can spell" line of argument, but I do tend to see some justification for the "If their writing is sloppy, unclear, and contains lots of errors, they're probably stupid" school of thought. I'm fully aware that's probably an Elitist point of view, but there you go.
When a pileup happens, I think it negates the entire advantage gained by "lubricating" blocks of law-abiding vehicles. The study mentioned didn't look at the likelihood of collisions as a result of rude driving behavior, so it's premature to advocate rude driving behavior as a means to reduce time spent in congestion.
- (a) meters that let information flow *into* our house from the electricity company (like "supply is currently tight, minimize your usage"). To which we can either instruct our own appliances to respond like "Ok, if it's really tight now I'll wait 20 minutes", or empower the "smart" meter to tell an appliance "Appliance XXX, switch to standby until I tell you to restart".
- (b) meters that let information flow *out* of our house to the electricity company "this household is now drawing XXX watts and has the following list of appliances on with their current power consumption {list}". (E.g. [Appliance_name, nominal power rating, maximum power rating, current power rating]).
I think we can all agree that type "a" meters aren't objectional and may be worth serious consideration. They just allow us to optimize our domestic electricity use, which is especially useful if we have double-tariff meters.
I think we can also agree that we do not want type "b" meters. This type of meter lets the electricity company monitor what amount of power each household consumes at what times and then lets it (a) influence those appliances directly or (b) allow them to model our individual power consumption pattern - at micro-level.
I'm not the only one's weary of the huge privacy concern. Burglars for example will make sure they quickly get access to such "confidential" and "protected" information. It's just great to be able to monitor the whole city for patterns of absence, let alone have full-scale real-time checks of owner absence, don't you think?
That idea of electric cars buffering peak demand from household appliances is fine and dandy, but how many electric cars are there right now? And in 10 years? How many households will be able to "mask" their peak demand because the car battery is supplying up the current? And besides, that car will need to stay at home *plugged in* for the duration of the peak demand. And it will need to be recharged *before* you can drive it. So: my guess is that you won't be able to use it to damp out the morning peak demand anyway.
The long and the short of it is that I believe that peak demand for electricity will be around for a long time to come. And with it peak prices.
Has anyone checked gov. Palin's whereabouts lately? Considering the article, that's what I would do first.
Who would have believed him if he had claimed, before submitting documented evidence, that on-line players would actually (a) get so upset in-game and (b) let it get to their collective heads and (c) blissfully ignore the way the game is set up?
Someone who plays roleplaying games on a regular basis probably would, but not the world at large and probably not social scientists either. It's the merit of his research that he exposed this strong impact of games on players' emotions.
It's also much more informative than anecdotal stories about this-or-that Chinese player killing another player for flogging his borrowed magical sword because it's systematic, controlled, and documented.
I'm afraid it also provides solid evidence that there may be valid grounds for *legislating* certain aspects of on-line gaming simply because these games have such an emotional impact. I'm not saying that legislation *must* be enacted, merely that online games aren't just ... well ... kidd's stuff. It also proves that grown-ups are a *lot* more childish than one might assume at first glance.
Whenever a management decisions will be visible to those who are not subject to the decision-maker's authority, "management" is often seen to drastically scale back the scope of what it first mandated as necessary, instated as "policy", and enforced. The downside is that climbdowns are rarely the result of a realization of "Oops ... what we did was really stupid, so lets not do it anymore", but mostly "Oops ... we're getting bad publicity on this one ... time to do some managerial damage control". Stupidity remains unchallenged (unless it can be used by a manager to discredit a rival).
This example is also a salutary lesson for those who thought that Dilbert stories are all based in an imaginary world. As Scott Adams said: many of his examples come from real-life occurrences that he either witnessed himself or were emailed to him.
Now that's a big part of the market we're talking about. So Google is rightly scared out of its wits.
Sorry ... can't fault Microsoft this time. It's finally delivering value to the masses.
As other posters point out however, the prowess of languages like Matlab and Octave at linear algebra, differential equations, etc. comes from the fact that in such cases the interpreted language merely acts as the glue between successive calls to subroutine libraries (BLAS, LAPACK, FFT, etc.). The amount of work spent in Matlab (or Octave) mainly consists of setting up the library calls and storing the results. The hard work is done in the libraries.
Of course this is of no interest if you just want to get the calculations done. Octave etc. will get you the right results, and make them easy to inspect and process as well. Therefore, provided you can arrange your calculations so that the bulk of the work can be confined to a couple of library calls, by all means: use Matlab, Octave, or Scilab.
However ... sometimes you need to carry out massively repetitive computations on data that is not easily expressed in terms of function calls to standard libraries. In other words: loops. When you code such loops in an interpreted language (like Matlab) the overhead of the interpreter is added to every iteration you do. To the detriment of your runtimes.
Now Matlab afficionadoes will contend at this point that you only need to configure loops as vectorized code to still get the speed benefits (because vectors are handled inside the libraries that Matlab etc. call). I agree that whilst sometimes loops can be so vectorized this by no means holds for all all of them. And even if the code can be vectorized, the process takes insight, effort, and concentration. On the other hand, coding an algorithm exactly the way you would do it by hand is a lot easier, and a lot more suited to the real world of non-programmers writing programs. What's needed in that case is a compiled language, not an interpreted one, which doesn't impose all kinds of overhead when you do loops.
Java proponents will rear at this and will proceed to wax eloquent about byte-code interpreters, JIT compilation, and lazy evaluation. Unfortunately Java is a very poor choice for numerical work. Mainly due to the way the floating-point stuff is implemented, and how the interpreter e.g. doesn't respect the flow-sequence of your code but feels free to substitute any expression you write with one that's algebraically (but not necessarily numerically) equivalent without ever telling you about it. This tends to disqualify Java from numerical and scientific calculations in favor of a language that allows the programmer more control over the way that expression evaluation is done.
Thus a simple compiled language is needed. Just about any third-generation compiled language will do. C or C++ for example will deliver the same kind of performance as Fortran. Pascal will do likewise. Ada is fine too.
However, as we all know, coding in C or C++ is not for those who are sloppy about implementation details. At best the code won't run at all. Even worse, the code may run and silently hand back nonsense. It takes time to learn how to program properly (and safely) in C and C++, which is something the average Chemistry or Physics student can ill afford. Even if he has the inclination to learn.
Pascal is great for clarity of expression in programming and maintainable programs. Unfortunately it's less well suited to writing reusable programs, and (barring non-standard extensions) its strict typing can play hob with resizeable arrays. And as soon as you go allow extensions, you lose compatibility. I can be quite confident that I can take my old standard FORTRAN-77 code and run it in Japan, Russia, France, and Brazil with no more than a recompile and get the same answers every time. Try that with manufacturer-specific add-
It's definitely not a language for amateurs in the sense of people who like to fiddle with the system, are interested in how the compiler works, or who just want to make gee-whizz web mashups. It's a language for people who don't care a rat's *ss about computers or programming, but who need to get their calculations done without wasting time on fiddling with pointers and who need reliable answers without being bitten by silent array-boundary overflows to boot. So Slashdot might not be the best place to ask for an opinion.
Besides, most of today's numerical libraries (BLAS, LAPACK, ATLAS, EISPACK, FFT) are written in Fortran. If you want to use them, you could do worse than learn Fortran.
True, it's not a language you'd want to do sophisticated datastructures in, or tree-searches or text-processing or payroll accounting or database manipulation. But especially chemists (and to a lesser extent physicists) have more call for numerical software than they have for non-numerical software.
So no. It's not at all ridiculous to teach Fortran as a first programming language to non-computer-science students. Alongside Matlab (or Octave or Scilab) it will do fine for chemists.
After all ... you're looking after the company's hardware, the company's network, and the company's main equipment: the PCs. You enable the company's Human Resources to do their work. If people make your work difficult, then the company may have a problem. Flounting company guidelines on how to use computers is one of those things that may make a company loose a lot of money very quickly (e.g. if someone downloads a virus that wipes out a lot of work (or worse, gets sent to a client), if someone installs a bootleg version of a software package and the BSA comes calling).
Managers tend to be sensitive to that sort of thing. So how about having a talk with your manager and asking e.g. for backup in enforcing company policy? Once you have the authority to check up on someone and land them in trouble if they misbehave, respect will follow (unless you start abusing that authority of course).
Vista is Microsoft's Edsel, but on balance the Edsel didn't hurt Ford all that much.
An Australian Space Agency? So they are finally going to explore the Outback? About time too !
Fuel cells for cars are interesting, but hydrogen is over-hyped. Vehicles powered by batteries or capacitors are also emission-free (looking at the vehicle) and viable and promising. At least for distances less then 30 miles (which so happens to constitute more than 95% of all trips). So it's not a critical technology but it's a "nice to have" technology. Besides, like Chu says, hydrogen powered cars are looking at a long list of pesky and fairly fundamental problems which will take time to solve.
I applaud the decision to set up 8 smaller research establishments for 5 years instead of "one big one". Less photo opportunities perhaps, but (taking into account that they will work with local research centers and with industry) more chance of someone having a bright idea. And long enough to make it attractive for someone considering what field to specialize in to choose energy research.
I also like the decision to let the government stop looking for oil and gas. We have private industries that are quite adept at doing that, and (as Chu says) they have plenty of money to fund exploration. So pouring government funding into it is a dead waste. It's nice to be able to pick up the tab for costly and risky research for your oil-industry buddies, but that doesn't help the public.
I think this shows what can happen when you put an actual scientist in charge of research. And yes, Chu's freedom of action is severely limited by previous commitments, including the one to do research and produce material for nuclear weapons.
Let's be blunt: if you're talented, a masters degree is easy and quick to do, and is probably your best bet regardless of any other considerations. Provided you complete it on schedule, it also proves that you are not just able to passively absorb and reproduce a lot of information, but also (depending a bit on what school you go to) that you are capable of independently applying the theory that's around in your area of expertise to a specific problem. That potentially makes you more valuable than someone with just a bachelor's degree, even if you have a little less on-the-job coding experience.
Unless what your prospective employer needs (or thinks he needs, or rather what his HR department thinks he needs) are straight-up coders who work hard and don't ask questions. In that case a BSc with more coding experience will be preferred.
In order to advance in the field you'll need to build a resume with successfully completed projects, in which it must be clear what *you* did (as opposed to the team you worked in). Writing a Master's thesis gives you such a project, which you'll have to do all by yourself (not counting all the advice and supervision you'll get). The point is that a Master's course is designed to allow you to shine, while work-experience is not. If you are really talented, you can show that in your thesis. What you will get in a workplace is a lot of simple tasks which, if completed in time and to-spec show that you're a solid production worker who may be ready for some more difficult assignments. In addition, if you're not the shiny type, your Masters work will still be a solid achievement.
If you think it would be hard to go on, then getting into the workplace is probably best. However, unless you show outstanding talent and/or managerial aptitude, your BSc degree will more likely slot you in a career as a coder than as a designer of software.
Last but not least. I don't want to scare you, but low-added-value work like pure (low-level) coding can easily be outsourced. To India for example. More complicated work, and especially work that involves a little thought and local knowledge is less easy to outsource.
A book based on the "lecture notes" principle which also tries to use the available space can typically cover the same subject matter in a clear and concise manner in a quarter of the size and weight.
That would be something Open Source textbooks can address.
I have only one plea: don't make e-books. E-books on laptops aren't as easy on the eyes as even poorly typeset hardcopies.
Clearly Microsoft's best interests are served by denying their customers interoperability.
That's what drives Microsoft's policy: cash. Everything else is PR. Which is duly born out by their actions.
First of all, the whole exercise was cut short because the botnet admins updated the Mebroot toolkit, causing the researchers to loose contact. That happened before publication, ok? Secondly it shows that the easiest way to protect your botnet is to update Mebroot once a week (or sooner), and savvy botnet admins already knew that.
The big plus is that this research unequivocally points out MS Windows users' ability to write to the MBR and to modify executables as the main strategic access point. The general public didn't know that before. Now it does and it might decide that this is something that must be addressed. Either by switching to Linux or by more careful login management or by pounding the desk in Redmond and demanding a fix. Nothing else could have done that.
In addition it highlights the crucial importance of ISPs and registrars to respond immediately (and intelligently) to complaints of abuse. As the researchers point out, there is scope for streamlining and actually *using* existing procedures to terminate a registrar's accreditation. There may also be scope for legislation here in compelling any ISP or registrar to maintain a certain minimum capability for investigating abuse, and for instituting a legally binding maximum timespan between complaint and investigation. I would personally favour legislation to force those registrars and ISPs who do not have that capability out of business (or compel them to be taken over) within a year or so. That's something that would have been impossible to justify without this research.
So in short, the small disadvantage of alerting botnet admins to a vulnerability is far outweighed by the intelligence gathered. Intelligence that *must* be made public before it can be acted upon due to institutional torpor, stupidity, or tardiness.
It's quite probable that this information (and particularly the techniques used to hijack the botnets) are also new and valuable to law-enforcement agencies. Such agencies tend to be desperately short of intelligence (both kinds), under-equipped to do research, and usually operate in a purely reactive way ("show us the bodies and we'll investigate").
And yes, I think that the researchers did fine by hijacking a botnet in the first place and secondly by not destroying it but instead contacting law-enforcement agencies. Researchers are neither law enforcement officers nor sysadmins for the infected systems. They have their own work to do (which law-enforcement agencies could not or would not do, or the Torpig botnet would have been cleaned up long ago).
It is interesting to note that *all* of the infected machines seem to be MS Windows based. Even though many of the targeted clients (Firefox, Skype) also run on Linux machines. If I had to guess I'd say that under Linux the need to have root access to either modify the MBR or to write downloaded malware code to the targeted executables on disk provides an effective barrier to infection (provided you don't surf the net with root privileges of course).
Unfortunately the publication of this sort of research may lead botnet administrators and designers to address the authentification weakness the researchers exploited. Ah well, such is life.
The problem is with improper use by those who use the (admittedly) sharp tools provides by quantitative financial modelers. One might intuitively expect bankers who are being paid six to seven-figure salaries to be able to see through and beyond financial models based only on statistical correlations, but alas, another hope dashed. Apparently the capacity for independent thought is not for sale even at those salary levels.
In the case of David Li, his copula is merely a convenient and computationally tractable way of doing calculations with multivariate Gaussian distributions. The problem is that the covariance matrix that describes the correlation of risks was calibrated on the *past* 10 years. Which is just fine if your multi-variate time-series is stationary. But misleading if there is e.g. a sudden regime change in your time-series.
Now the past 10 years were years of growth, wealth, and plenty of borrowing and the US of A are a rich country and its citizens can borrow an awful lot before there is any problem.
As a result all the banks saw a _low_ correlation between person X being unable to service his mortgage and person Y being able to service his mortgage. Therefore the road to financial safety for mortgage lenders was: make your portfolio big and make it varied. As big as possible and as varied as possible. And then make it even bigger. Because the Law of Large Numbers guarantees that the probability that large numbers of your clients will be unable to pay is quite small.How small? Well ... you can calculate that to a nicety using 10 years worth of financial data. And you can budget for that. Great huh? The only thing you need to assume is that next year will be just like the past 10 years.
Any bank manager who wasn't prepared to sail as close to the wind as the financial models indicate was possible was sacked by his boss for not being result-oriented enough, which is a fairly broad hint for the remainder.
Unfortunately the correlation matrix, on which all those risk calculations hinge, is not a constant. It may change if massive numbers of borrowers suddenly hit their collective borrowing limits. When *that* happens, the probability of person X being unable to service his mortgage suddenly becomes a reasonably accurate predictor of person Y not being able to pay up in time. And the amount of risk you run with your huge mortgage portfolio suddenly increases dramatically. Which is exactly what happened.
Suddenly all the correlations went up, and banks found themselves sitting on enormous amounts of mortgage-backed loans which they couldn't even assess the risk of because they didn't really know the new correlation matrix.
This had two effects: first of all no bank would be happy to lend to another anymore because if it was hard to assess one's own risk position, it was impossible to assess that of another bank. So lending to any other bank was basically taking an unknown risk. Which they either refused to do (if they were short of cash themselves) or which they charged much higher rates for. That was the birth of the liquidity crisis.
The second effect was the use of "slicing" the mortgage portfolio. That works as follows. You take a mortgage portfolio and you (hypothetically) sort its elements by probability of defaulting. Then you package the 10% highest risks as a new investment product. And then you sell it. You (honestly) tell your clients that it's high risk (and you tell them how high the risk is), but you offer a commensurate yield. Repeat that for the next 10% and so forth. In principle this is a fine idea which make
We have an extensive and poorly secured (as no un-passworded systems, vulnerable dictionary-based passwords, no system auditing, almost no network auditing) IT infrastructure, we have loads of national and international computer burglars banging away at it, we have a lot of people who know something about IT looking for a job, and we have a government looking for sensible ways to spend money so as to alleviate the recession.
Am I alone in thinking that it would be money well spent to set up 3 or so military schools in the US specifically to train network administrators? Students to enlist for the duration of their training (basic raining plus 2 years specialist training), subsequently 5 years of operational service as a sergeant. Graduates of this course to be unconditionally qualified for all basic network security and operation anywhere in the government (from local to federal).
It helps protect both our civillian and our military IT infrastructure, it builds a reservoir of people who know how to secure and operate a computer network for any government agency to draw from, and it provides jobs.
So ... how about it?
Just ask yourself if you'd be comfortable with the company controlling these orbital beamers being Chinese.
If you aren't, then it's a given that other countries will feel the same about US companies being in this position. And perhaps it good to bear in mind that the Chinese will probably have the money, the technology (or the spy-craft, which amounts to the same thing), and the will to replicate any such stuff within 10 years or so.
This sort of technology has such a (potential) impact on Earth itself that there are many legitimate stakeholders besides those of the US. As I see it, if we go about it with a "finders keepers" and "whoever has control has the right" mentality, that will come back to haunt us within 20 years.
Therefore I think it's probably a good idea to turn to the UN and legislate and regulate this sort of thing (i.e. orbital satellites beaming back industrial amounts of energy back to earth and trying to squelch hurricanes) before it happens. And for preference to have some sort of mechanism that makes certain that one country can't turn its deserts into a bread basket or its permafrost into a garden by e.g. disrupting the weather elsewhere. And to prepare some kind of enforcement (anything from communication cutouts to override codes to lasers to EMPs or missiles).
If we're quick about it, we can probably shape this regulation to suit us and any other reasonable party.
And all the relevant details will be in the "but".
When you consider the buts, you also discover that the question really isn't "Can rail work in the land where the car is king?", in the sense of "can train compete against car?" because the answer is a simple "No". Population density in any area that features large acres of suburbia is too low for the train to be a meaningful competitor for the car. Simply because the US have been grown that way for about a century. There aren't going to be any trains for commuters from the suburbs to the central business district, or even from the suburbs to the industrial areas.
The question is rather: "Can we find corridors in which the train will be competitive with both the car and the airplane". And the answer to this question is: "Yes, certainly.". The trick is to find heavily traveled routes that currently have a moderate to poor level of service. For example the Boston - New York City - Washington DC corridor would be well suited for a high-speed train that can travel in, say, 3 hours from Central Boston to Central Washington and which will also stop at Logan Intl., La Guardia, and RR Intl. Being able to reach both the airport and the city center will be crucial. The city centers because that's where most people need to go anyway, and the airports because they allow the train to provide access and egress to the air transport network.
The interesting thin is that a good train connection can be both quicker than air, bus, and car. Air because a train link can (if done right) dispense with time-loss due to check-in and the constant juggling for departure slots, boarding, and taxiing that's inherent in air travel. Buses and cars because both cars and buses are will be affected by congestion, and because of the speed limit on the highways.
It's possible to build a successful rail link in that corridor, but it will either take about 10 years to build because of all hard infrastructural problems (read acquisition of land and demolition of anything that's in the way of access to the city center and the airport) that need to be solved to get to the desirable areas (city centers, airports) or it will not connect to those vital points. If the envisioned rail service doesn't connect to the city centers and the airports, it will offer a service to take people from where they aren't to where they don't want to go.
So, yes, it's possible to build a successful rail link, but it's much easier to build one that's an absolute disaster. Financially, politically, and transport-wise. So don't get your hopes up too far.