Posts by Stephen Booth 83 publicly visible posts • joined 9 Oct 2006
If the web-site logs people out when the ip address presenting the session cookie changes then its going to be a lot harder for the attacker to do anything useful with the cookie even if they can steal it.
You might get spurious logouts if your device re-connects to a network with dynamic ip addresses but that is probably acceptable in cases where you care about security.
Yes the iphone was and is a huge success and caused a big change in the market but
not because of patentable design or technical innovations.
This was a marketing success.
Apple took a hugely successful and fashionable product with an existing fan base (the ipod) and added the ability to make phone calls.
Lots of existing phones already played music but it turns out that people would rather buy a really good music player with a crap phone function than a good phone with a crap music function. Sure it had to look nice but I doubt the success was just because it had rounded corners.
Good and insightful reading of the market that everyone else has tried to copy but not patentable.
I'm not sure. SeaMicro have a working product but Intel sell chips and it would take a while for their customers to build the new chips into their road-maps.
Its always going to take a product cycle before something like this makes an impact and I think the SeaMicro lead will be eroded by then.
The Cloud virtualisation and HPC markets are all about large numbers of tightly integrated cores.
From Intels point of view it makes a lot of sense to integrate the network onto the CPU (either directly or via a chip stack) and with AMD going this route they can't afford not to.
If the CPU manufactures start integrating networks then the independent HPC network vendors are doomed in the long term.
Cray needs Intel so its a much better deal to sell them the technology than to try to compete with them.
"E-beam lithography itself is pretty straightforward," Liebmann said. "We all sort of qualitatively understand how this all works. And we all also understand that the biggest problem is throughput. What all of these systems are working on is massively parallelizing the system to get to a point where you can begin to make this profitable."
EBL may not have the throughput for profitable mass production but as I understand it you don't have to make masks either so the cost should be similar for small volumes and prototyping as it is for large volumes.
Just as 3D printers (much more expensive than mass produced injection mouldings) open up new possibilities EBL might already be interesting for the low volume specialist designs that currently use FPGAs. Maybe what we will see is the current small number of dominant chip designs built in huge global fabs being replaced by a wide range of custom designs printed to order. This might make things profitable even if there is a big hiccup in the expected price reduction with each processor generation.
The problem with Java according to the evidence presented seems to be poor auto-updating and a large install base of old versions so that old and vunerable versions of java are frequently available for exploit.
This is a real problem for the internet as a whole but not an indication that up-to-date versions are inherently less secure than up-to-date versions of other plug-ins.
There are two fundemental problems with conventional 2D DRAM.
1) The number of available pins on the device is proportional to the chip perimiter so the available connections between memory and processor grows much slower than moores law.
2) DRAM cells are built with specialised high desity processes so you can't add much in the way of additional logic on the same die (while keeping them cheap to manufacture). DRAM chips therefore connect via simple signaling where the energy cost is proportional to the capacitance of the wires and the frequency.
By stacking chips and using TSVs you get round both problems. The number of TSVs that can be supported is proportional to the chip area and the connections have extremely low capacitance.
I'm assuming the plan is to put efficient RAMBUS style high speed serial interfaces in the logic layer to connect to the CPU.
This keeps memory and CPU as seperate devices and allows standard memory devices to be used with different types of CPU However though better than what we have at the moment high speed serial interfaces still take power.
The right place for TSV stacked memory is right on top of the processor with external memory devices only used as a top-up for higher than normal memory configurations.
I still have an almost complete collection of every processor board Meiko ever made (complete with the green wire field modifications on the back).
One little known feature of the transputer was it supported multiple execution threads (including the thread scheduling) in hardware. Modern chips also support multiple threads but the OS is much more involved in the scheduling of them.
The transputer was not a multi core processor so only one thread actually ran at any one time but the threads were there so you could specify your problem as lots of tiny micro-tasks that automatically switched to a runnable state once their input data was available.
The interesting thing is that many of the programming models being proposed for future exa-scale systems are returning to this kind of thinking so we may see a return of designs like this.
I looked into something similar myself a number of years ago. It is very very hard to do this in an unbiast way.
My results were that the actual compilers (I'm including the JVM JIT in this) tend to be equally good at optimising code. The difference between different languages is that the different language features tend to cause the programmer to make different design choices (some choices are just not available in some languages) these effect performance.
If you can identify the performance critical sections of the code and encapsulate them (and their data) then it is possible to re-write them for performance however these sections tend to look very different to "normal" code in that language (e.g. Java code that uses arrays and looks more like C than java).
I'd be willing to bet that the winning C++ verision was making heavy use of templates (template metaprogramming) this is really a language all of its own and can give very good performance but (IMHO) damages the code in terms of maintainability and intelligability.
Even if it does not make sense in the short term it is not suprising that Apple is looking seriously at ARM. Not becasue it is obviously better for the users but it is better for Apple.
Apple is still primarily a hardware company but the ongoing trend in hardware is for more and more of the important hardware to be combined into a single device package. Any company that sticks with Intel are going to end up putting a cosmetic case around the Intel package as all their competitors. This makes it hard to be different enough to charge much of a premium for your hardware.
Things are much easier if you license ARM and build your own processors. Even if most of the hard stuff comes from ARM you still have plenty imput into the design and you can take that oppertunity to make sure your software won't run on 3rd party hardware.
Now I know that Apple are the world leaders in getting people to pay a premium for hardware that is not very dissimilar to everyone elses but there must always be a risk that they might get landed with a legal ruling unambiguously legalising the hackintosh. The more markets they can move to the iphone/ipod modle the better from their point of view.
This might be the only easy way that the industry can continue to deliver the moores law performance increase that the market expects.
People have started to notice that adding cores without doing something about the memory system is only giving a modest improvement in many cases.
I think the memory is going to HAVE to be stacked directly on top of the chip. We have already reached the point where there are not enough conventional chip pins to feed the cores.
So the big processor manufactures will be producing single devices that contain all the major components of a server, cpu, memory, 1st level network, and flash storage. Turing these devices into servers is going to become a very low margin operation with very little differentiation between box builders. Good for anyone making processors, bad for people futher down the food chain.
How many times do we have to listen to the argument about getting a free ride from the apple ecosystem.
The vendors don't want to distribute their content through the app store. All they WANT is to enable their customers to use devices (which the customers paid for) to access the services the vendors supply. They would be quite happy to serve apps and content directly from their own websites never involving apple at all beyone making the hardware but apple insists anything involving an iPhone has to take part in their ecosystem. Yes apple make good hardware but that has already been payed for!
This is not the case of a fair payment for an essential service, but a a service that apple has artificially engineered to be essential so that everyone has to pay for it.
The article makes a number of points about how a single-stop online software shop has some advantages over having to track down the company website.
There is absolutely no reason this store has to be run by the device manufacture!
As a consumer I happen to have a preference to buy music downloads from amazon rather than itunes.
If I want an environment that automates the software install process and allows me to use my bought software on multiple computers, this can also be done by third part providers (look at steam for example).
If the users want app-store style delivery of computer software then we should expect multiple players in that market. Apple has a bit of a head start due to the phone segment but unless they try to lock down macs like iphones they are going to have to be a little less dictatorial.
The thing about zany military tech is that does not have to work all that well or be deployed in large numbers to be worth having.
OK there are lots of ways of countering a super laser but its going to cost the other side a lot of money to develop these especially when they are not sure how well your super laser works.
The more laser shielding you can persuade the other side to put on their missiles and planes the less effective they will be.
Yes subs are probably immune and its probably easier to harden surface ships than planes.
Thick armour plate would take a while to melt and might help against rail-guns too. No wonder the navy seem keen on this.
I can see why this looks attractive to Apple. Lots of new features that you can only get if you have an iphone but I fail to see the advantage to retailers and product manufactures who would have to carry the recurrent costs.
* Lots of expensive new features that only some of your customers have the right phone to use.
* Advertising etc. only accessible to members of the public who are already holding one of your products in their hands (not a key target demographic).
Existing phone apps that scan/read barcodes and chips that exist for other purposes are fine because they add value to the phone at minimal extra cost. Telling the retail trade to choose a technology because it would let phones do something funky is just arrogant.
I'm not sure x86 compatability is important. HPC codes are not written directly in x86 assembler and to a very large extent are re-compiled for each system rather than being distributed as binaries.
Historically the HPC market has been happy to migrate to whichever architecture provides the most value for money. The current dominance of x86 chips in HPC is more due to the price performance benefits diven by the mass market in x86 chips than by any requirement for x86 compatibility from the HPC market. This would argue that graphics chips have the advantage due to selling in two markets (unless of course intel subsidise their HPC only chip).
Programmability is an issue but the PGI compiler already targets nvidia GPUs to accelerate normal fortran codes. There are problems with targetting attached co-processors with their own memory but these would also be experienced if the attached processors are x86 cores.
Of course x86 compatibility does mean you might be able to build a large MPP system out of ONLY Larrabee chips which might save some money.
The problem with the cloud buzzword is that it means too many things to too many people.
Google App Engine is a mechanism for doing business with Google. Of course it is locked to one vendor and nothing intrinsically wrong with that and you get access to lots of nice underlying technology.
But there are lots of cloudy ideas out there that don't map onto App Engine (people are talking about using clouds for large number crunching jobs for example) and the ability to use multiple vendors is also important to some people.
This does not mean that App Engine is bad or inferior just not appropriate to these cases.
The problem is that people write stupid surveys about "cloud" as it meant a single thing. Different companies have different cloud offerings targeting different use cases. Google provide an offering that is specific to their infrastructure so inevitably has some degree of lock-in.
And 26 percent of respondents did not realise this or voted for their favourite company regardless of the question.
Big installations with a chilled water system and a cold climate have another option. When the weather is cold enough we switch off the chillers and pump the water through a free-cool radiator system on the roof.
Takes a lot of additional plumbing and you still need to power the pumps but you keep control over dust and humidity.
VM actually got things right with the i-player they upload the content into the cable-TV on-demand infrastructure.
This means that we can watch catch-up TV programs on the TV (amazing concept)
and use the same interface for catch-up TV from non BBC channels as well.
Even better I can grab the laptop and use the broadband while my kids are watching the i-Player programs.
No OS can be proof against user stupidity. No matter how secure it is if the owner of the machine is stupid enough to try and install software of unknown origin then the machine is going to get infected.
Its therefore no wonder that an OS thats shipped by default to home users has a higher infection rate than an OS thats typically only used by IT professionals.
I'm no great fan of Vista but this seems a bit bogus to me.
I'm with the pro water cooling crowd.
Water cooling might be a bind if you are thinking in terms of a small server cupboard cooled by through the wall air-con units, but once you have a whole building full of the beasts then your air-con system has to be driven by a massive chilled water plant anyway.
In this case getting the chilled water closer to the source of the heat has to reduce the overall power use.
The only time I remember a big puddle of water under the machine room tiles it was not a failure of the chilled water system but the dehumidifier drain pipe got blocked and it was the air-con system that caused the flood.
The exact form of the opt out cookie is absolutely key here.
If all opted out users have exactly the SAME cookie then it can't be used to track your usage. If it contains a serial number then somebody will have to write a browser extension to generate a random opt-out cookie for every new web page.
That way they will have to use your ip address to track you and the ISP has always been able to do that with or without phorm.
For that matter how about a randomly generated opt-in cookie. That might give them a few headaches for a while.
The whole thing would be much much more stable, scalable and easier to accept if it ignored all streams without an opt-in cookie.
Why does this system have to opt in by default when they can target webwise ads to anyone without an opt-in cookie !!
Call me cynical but I bet they are going to do is base their choice of ads to serve you based entirely on your interaction with search sites.
Its going to be a lot easier to identify somebodies interests from their search terms and click-through than anything else.
you could see this as an attempt to undermine google by getting access their raw data.
There are two parties to every communication. They may be able to claim that the user has opted in but the web-site sure as hell has not. If I was google I would sue them to make sure they don't intercept anything from my site.
of course they probably want all the other data as well not to target ads but to sell on. Even anonymised that data is valuable to somebody.
Probably the right solution is to force the encryption keys to be unloaded at every point which would also cause you to have to have to re-enter your login password later.
screen locks, hibernate, sleep, switch user etc. should all dump/overwrite crypto keys immediately if you have to re-authenticate your login this must be because there is the possibility that somebody else has access to the machine in between times so you should expect to have to re-authenticate your crypto at the same points.
What we really need is a good OS hook that allows any process to be notified of this kind of event and dump any keys that its holding. There are lots of different processes that cache security sensitive data in memory, ssh-agent, browsers holding unencrypted passwords etc
I recently switched to netbeans 6 after a couple of years on eclipse.
The best reason for switching is that NB uses the sun java compiler.
The eclipse compiler and the sun one have some disagreements about what is valid code when it comes to some uses of generics. I just got sick of having code that compiled in eclipse failing when built with ant.
All the really big HPC systems on the top-500 have only a couple of cores per node. Beyond that and memory bandwidth saturates. For HPC type applications most of the parallelism comes from large node counts. Unfortunatly using multiple nodes is much harder than multi-threading.
In my opinion very large core counts will only work for niche applications unless we start to see some inovation in memory system design but the memory manufactures seem only to be interested in making larger chips of the same old basic types rather than investing in significantly new technologies. Whatever happened to rambus?
To those of us in the HPC community this seems like very old news. Every major supercomputer for the last 10 years has needed parallel programming.
However in this arena we have long since hit the point where codes are limited by the memory system more than the instruction rate. For this reason most really big systems are distributed memory rather than thread based. If you think thread programming is hard you should try distributing a problem across multiple memory systems.
Intels move to massive core counts could have one of 2 outcomes.
1) large scale scalable shared memory systems become commodity and the HPC arena becomes much easier.
2) people discover that having lots of cores attached to a rubbish memory system goes at the same speed as a couple of cores no matter what you do.
Guess which one I believe :-(
Part of the difference is just that Java has colonised the SQL/XML space so effectively that new projects that require this naturally gravitate to Java. I don't think that the performance difference between C++ and Java is really significant enough to motivate the switch to C++ by itself.
I've done quite a bit of performance comparisons between the two languages and with a good JIT I find the variation in performance due to different programming styles much greater than any inherent speed difference between the languages.
I also feel that because the core Java syntax is much less rich than C++ (not that I mind) there is often only one way to approach a problem in Java where C++ gives you a choice of four or five. In a perverse way this makes code re-use more likely.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
