Posts by Stephen Booth 76 posts • joined 9 Oct 2006
The CBM PET was also the first computer I ever used.
I remember the unusual approach they took to supporting different hardware configurations. The low memory version of the PET had exactly the same mother board as the high memory versions including the soldered sockets for the memory chips. However a big hole was drilled through those sockets to make them unusable
I'm not saying I'm in favour of the scheme but I don't see any problem in principle supporting the basic concept of encrypted home directories with ssh. Its only a convention that requires ssh authorized key-files to live in the home directory.
The encrypted directories could have some unencrypted envelope meta-data. You can put the ssh public key in that.
SSH also does not have to use public keys it can delegate to the normal PAM library. As users are going to have to put in a password to decrypt the diretory anyway you have already lost all the benefits of using public key authentication anyway might as well just prompt for a password.
Supporting encrypted directories where the key is only present when the user is logged is a good (and not new) idea. Taking a religious position that all information about the user must be encoded in one of these is just making things over complicated.
Everybody is talking about this being outsourcing and they should have stuck with their in-house tech people.
My reading of this is that they are switching between two outsourcing suppliers. They lost any in-house system when TSB was spun out and were being held over a barrel by lloyds so they hired somebody to create a replacement platform and got shafted again. Probably because the bank does not have its own technical staff to evaluate the solution properly.
The lloyds in-house techies who were running things till last week are probably still at their desks business as usual.
Part of the migration is a change to a new server.
online.tsb.co.uk -> internetbanking.tsb.co.uk
If you go to the main TSB site and follow the links you get there and It appears to be UP
If you use an old bookmarked you go to the old server which shows as still DOWN
Also the site could remember your (unmemorable) username for you via cookie but (inevitably) you need to actually type this in the first time you go to the new site.
These changes by themselves would cause lots of people problems so even If everything is working now I'm not surprised people are still seeing it as down.
The real comparison with SpaceX hardware is with the new Raptor engine not the production merlin.
Raptor uses the same fuel as BE-4 and is at a similar stage of development (Raptor first test fire was last year)
It does look like Space-X have dialed back their target thrust for the Raptor so current indications is the BE-4 is the larger engine but this is the first test-fire it is almost certainly not running at full design power yet. They probably do have to come close to their target because they don't have the flexibility that SpaceX has to redesign the rocket.
I have similar concerns to some extent. In principle JS may have a security advantage because it started with a much more limited scope than a general purpose language. A language whose only purpose is to manipulate a DOM tree might be easier to secure. However everybody seems set on expanding this scope to general purpose compute and the JSON parsers are so complex they may very well contain potential exploits. Only time will tell.
Ecmascript (aka javascript) is an important language in that is the most widely supported language for running code in a browser. If that is what you want to do then its the right thing to learn. I really don't see the point in running it elsewhere, though I will concede that there are some advantages to using the same language in both client and server I personally don't find the argument for its use on the server side compelling.
Though I'm hugely impressed by the performance of modern javascript engines and the utility of libraries like jQuery I actually don't like the underlying language much.
I recently went through the process of porting my 20+ year old classic fractal hack
https://spbooth.github.io/xmountains
to javascript. Once I got past the superficial resemblance to Java the language actually reminds me more of perl. Very useful in the appropriate context. Large number of powerful libraries available. But you spend far too long debugging small problems that would have been flagged as compiler errors in most languages.
Not knowing any javascript can be limiting, only knowing javascript more so but heck everyone has to start somewhere and at least if you teach javascript first you don't have to worry about students installing the development environment and also gives immediate access to pretty graphical results. Kids these days just don't find hello world impressive any more.
"what more does your job need except a CPU, some RAM, and some storage, which any VM can provide"
Depends on what the application does. Physical location, access to internal networks, availability when network access is lost; are all requirements that mean you might be better with a cat in your kitchen than a cow in the dairy.
However I'd moved on to talk about applications not servers at that point anyway. My point then was that the software applications you run on your servers are probably still pets not cattle. You were probably running them virtualised in-house and outsourcing the virtualisation to some cloud provider probably does not change anything fundamental in the way you treat it. Just because the cat actually sleeps next door does not make it a cow its still a pet.
What people forget is that cattle ranches assume some requirement to scale where pets come in small numbers and live in the house.
If you are keeping one cow as a pet in order to have milk on your cornflakes then you are being inefficient and would be better buying your milk from a large dairy herd.
If you are keeping a cat as a pet to kill the mice in your kitchen then the dairy herd is not providing the service you want and not providing it where you want it.
Its also not as if you have mice every day the lazy moggy spends most of its time asleep anyway its there as a capability rather than a capacity resource.
Even if you go to the cloud for your infrastructure many applications are likely to remain pets because they address a problem that only your organisation has and have fairly modest resource requirements.
If your main application allows arbitrary redirection to code it would not normally call then I would assert that you have already lost the security war. The bad guys WILL find a way to break you no matter what your dependencies are.
If you can arbitrarily call code in an included class library you can also call the core java libraries to do pretty much what you want.
Now the Java language does have a second line of defense in it has a sandbox and some support for running "untrusted" code. You are entirely right that if you are relying on the sandbox for your security then having code that contains vulnerabilities that can escape the sandbox linked in to the application would be a big problem. However the fraction of modern Java code that actually downloads remote code and relies on (or even use) the sandbox should be tiny. and the fraction of known vulnerabilities that allow the sandbox to be escaped is also tiny.
Just because an application CONTAINS a component with a vulnerability does NOT mean that the bug is exploitable in the application. It is very very frequent that applications will include a jar-file for a very specific purpose, pass a very restrictive set of inputs to the code in question and exercise a very small fraction of the included code. If the application never calls the part of the component with the bug and can't be persuaded to do so then the application is still secure.
I'm not saying that this is never a problem but just looking at component dependencies is making some serious worst case assumptions.
You are missing the IT angle to this. Some of the STOR generators (our 2MW for example) are Data-center backup generators. It makes economic sense and ensures the generators go through more test cycles than they otherwise would. And if the grid is going to be unstable its much better that the power grid people switch us over to backup before the problem becomes critical.
"with four in five not requiring the use of a capital letter and a number/symbol."
The thing that is important is entropy. Requiring particular characters does not help with this much it is a stupid hang over from the days when only the first handful of chars in a unix password were significant so using the full character set was a good idea.
If you enforce special chars all you get is "password!" instead of "password" same with all the other hard to obey password rules everyone uses one of a small number of common fixes to bypass the rule.
Probably the most important rule to enforce is the minimum legal length of a password.
The aim is not to increase the operating temperature of the components but the inlet temperature of the cooling. "Cooling" is not about temperature it is about energy removal. Energy removal depends on the specific heat of the cooling medium, the flow rate and the temperature change. If you use a cooling medium with a high specific heat (water) and move a lot of it really close to the source of energy you can get that energy out without having to chill it to really low temperatures first. Secondly there are other important factors driving equipment replacement cycles if you are planning to replace the equipment faster than it wears out you might live with a higher degradation rate if it reduces your power bill. This kind of thinking really only comes into its own for HPC or hyperscale where you are buying equipment by the room rather than by the rack. Free-cool and hot-water cooling are not exactly the same thing. Freecool requires highish input temperatures (higher than ambient). hot water cooling is about having a high output temperature so you can use the waste heat usefully. The strangest proposal I ever saw (unfortunately I can't seem to find a reference) was to use the waste heat to "digest" cow waste producing methane to generate more electricity.
The US courts do not seem to recognize any limits to their jurisdiction, hence requesting MS to hand over data in Ireland.
However I think the key difference here is that even though MS can technically access the data they can claim (if they so wish) that the data is not held by them so any court order requesting access to the data becomes a court order telling them to hack a third party. Not even the US legal system should be able to force a company to perform an illegal act so MS can appeal the order saying the court should make the request of DT instead getting MS off the hook without showing contempt for the court. Under US law (which seems to have no problem claiming jurisdiction over the entire universe) DT might also be required to hand over the data as well but it is in a much better position to fight such a request.
I suspect the premium change might be necessary to strengthen this claim and avoid DT being ruled a MS subcontractor,
MS could do something similar by spinning off their Irish datacenters as local businesses except that might unravel a lot of their current tax avoidance schemes.
"However, the fact that data resides in the UK may be false reassurance from a data protection perspective, since the US government argues that if it is in data centers belonging to US corporations, it still has right of access to that data."
Under the current structure the US government claims this right. If Amazon wants the option in the future to relocate and escape this problem it can probably do so quicker than it can build a data-center.
The other issue is the network. Amazon marketing will tell you that you can place your data anywhere in the world and access it over the internet. This won't work for anything latency critical and if everyone moves to amazon the owners of the trans oceanic cables will know exactly where to go to ask for more money.
Everyone knows that Amazon gets huge economies of scale with large data-centers. There must be a point of diminishing returns after they get to a certain size (amazon must have the best handle on where this point is). Once you get to that point you open additional centers at places of good network connectivity (and cheap power) the uk scores highly on the first of these less so on the second. Maybe they they have some clever idea about how to power it.
Though I'm sure the market applies to low paid jobs I'm not sure it always applies at the top.
Sure there are some talented individuals who build their own companies from scratch and have a huge responsibility for the value of the company. However in many companies the size of the company is so great that a small number of unjustified large payouts at the top have no impact on the market price of the shares. On the other hand any attempt to oust the current management would impact the share price so the shareholders and the market as a whole turns a blind eye. As long as only the small number of people at the top have their hand in the till the market does not care. These people are not being paid for the value they add to the business but are taking a "commission" out of the value of business that crosses their desk.
Interesting question for a future article, are commission based rewards good for the health of a market or do they encourage volatility for its own sake? Compare and contrast a Tobin tax and a traders commission.
For a really good author I'll buy the e-book when its first published. Especially for a series I've been following. However most of my ebook reading recently has been books from independent authors who basically self publish through amazon. These guys really understand about setting costs as often the first book in a series gets discounted to zero for a period to pull in new authors. However many of them are also really good authors and I find myself coming back time and time again because their per-book cost is well below my impulse buy threshold. Hard part is finding the good authors among the dross but once you find one their website often points you at others.
I'll point you at:
"The Utterly Uninteresting and Unadventurous Tales of Fred, the Vampire Accountant"
by Drew Hayes as an example of this.
The assumption in this article is that MS has to succeed in the phone space.Yes the decline in the PC market is partly due to a certain class of PC user finding a new class of device that fits their needs better. This is a fragmentation of the sector into two markets. Just because people used to use horses for travel and the plough does not mean the future belongs to a unified tractor-car hybrid. Tractors and cars might be made by the same company and use the same basic technology but its not the same product. Apple does ok making a phone and computer the same way Honda does ok making tractors and cars but they are different products. Not every car/tractor manufacturer has to make both and nobody succeeds with a unified solution even if some of the parts are the same. In fact market fragmentation is better for business because apple can sell you a phone and a laptop if you need both.
Phone/music-player/camera combination seems to work as a combination because they are all portable devices you want to carry around and separate devices would compete with each other for pocket space.
Microsoft can't seem to do phones. Apple have never done much in the games console space they both compete in the PC space. Once upon a time Microsoft managed to expand their market by making windows a server as well as a desktop OS and this has resulted in a fetish for using windows as a solution to every problem. Its not.
Kindle unlimited is rental not retail.
You get access to any book on the "unlimited" list while you continue to pay the monthly subscription.
Stop paying you lose access.
Paying by pages read might make sense in this model.
However my personal choice is to pay for each book I choose to read. I seem to be reading a lot of the self-published books at the moment because the buy price is generally pretty low (below my why-not threshold)
On the whole I don't think I'm paying extra other than when I really get into a book and go through the 7 book series. In which case I'd rather the money went to the author.
Running ANY programming language inside the web-browser is a bad idea. The more capable the language, the worse idea it is. If you can change the web-site applets can trivially be changed into jnlp downloads solving the problem. If you need to access an applet based interface that has not been converted then just open another browser when you need to (you could even write a stand alone program specifically for running java applets from web pages). Lets face it java applets never integrated well with the surrounding web-page so losing the ability to start them seamlessly is no big loss and easily worked around.
I think "Patch" implies that the software binary needs to be updated in the cloud providers. Thats misleading.
The bug is in the browsers. If the server is CONFIGURED to allow weak ciphers to be negotiated then a man-in-the-middle attach can be used to force a buggy browser to negotiate a weak cipher even if it is configured not to.
The server can prevent this from happening by a configuration change only. Of course removing support for weak ciphers in future releases is also a good idea. It also means that its even more unforgivable that services are sill accepting these obsolete ciphers because it just means nobody bothered to change a config file.
Office 365 is the product. The number of potential users for a cloud based office suite does not change depending on the relative popularity of android and IOS. The only difference occurs when one platform becomes so unpopular that client support for it no longer influences the choice to use office 365.
I don't think the recent reversals are anywhere close to that yet.
Support for android is not about shifting large numbers of apps but saying office 365 is device neutral.
You have to realise how long ago 1987 is. This is the year before the Morris worm (which came as a real shock I can tell you). An era when default passwords to allow the DEC engineer access to your VAX was normal. Also five years before the CERN conference where I first heard about the world-wide-web which was at that stage an internal tool that just a few non-particle-physicists were starting to use.
Our data center has an agreement with the power supplier that gives the power company remote control to switch us onto our backup generators at times of high demand. Not a huge power capacity from their point of view (couple of MW) but useful for short term spikes. From our point of view it helps ensure the system gets tested more frequently and its probably better to be switched over cleanly before the problem fully develops. Making better use of the distributed generation capacity at customer sites is now much more technologically feasible than it used to be. I't won't do anything to address the lack of bulk capacity but it will help ride through shorter events.
Except that in a few years Intel is also going to be a SOC vendor. The unavoidable economics of the semiconductor industry drives towards greater integration in devices. Even things that can't be integrated onto the same wafer are better when integrated into the same package. Recently Intel has been buying interconnect IP like there is no tomorrow, and it would be a good business move for intel to produce Intel defined servers in a single package in order to take a higher fraction of the overall product value.
If I'm right about this then in the x86 space Intel will define pretty much build full servers in single packages; traditional server vendors will only be able to compete on form factors not technical specs. In this case I expect a lot of them to experiment with their own SOCs based on ARM. However these would be future 64 bit arm cores designed as single package servers with all the hardware differences hidden in device drivers produced by the server manufacturer you won't be changing your code any more than you change x86 code when switching from dell to HP.
Certain segments of the server market (apache mysql java) run on ARM fine. In particular most java based services will port trivially.
A root and branch replacement of x86 hardware is unrealistic. In the short term I see ARM starting to make some inroads in the areas it already does well but with a lot of vendors taking ARM very seriously in development just in case.
The difference is that though JAVA does have a security model it is also a fully features programming language with existing class libraries to do almost anything so when you break out of the sandbox you have all the tools available to do anything you want. In addition there is a much larger functional space to look for holes in. On the other hand if the platform has no security model but only generates graphical output you probably need to find a way of inserting new executable code insert to do anything. Add in the poor update handling and java starts to look like an attractive target despite its security model.
The real interesting thing to watch is going to be javascript. Because it is only targeting presentation and network facing operations it can be reasonably sandboxed away from the underlying hardware. However this does not help you at all if all your data has moved into the cloud and there is nothing of value left on the local machine. I suspect over time the black hats will cease to care about trying to take-over the browser except as one possible route to owning online accounts.
Yes the exponential increase in the cost of fabs mean that Moores law is close to the end if not already ended. At some point we will be able to builder smaller transistors but there just won't be any point.
We will have to get used to a minimum cost per transistor just as we have got used to a maximum practical clock speed. However there are plenty of worthwhile ways of improving computers to explore other than just blindly throwing more transistors at the problem. None of these are going to give us decades of exponential improvement but they are worth pursuing. The good news is that once the transistor process (with its huge fab costs) stops taking centre stage then it becomes possible for smaller companies to innovate and compete.
The GPGPU market is an example of this. Floating point performance in increased over conventional multi-core by using smaller compute units and using a greater fraction of the transistors for floating point units.
Chip stacking won't reduce the cost per transistor. Each layer needs to be manufactured and you may ruin some good layers by bonding them to flawed ones. However it may reduce energy consumption and drastically improve the communications between different components.
The future is going to be interesting.
The external Centaur chip opens up other possibilities as well. Such as the Hybrid Memory Cube.
At the High end like Power8 its a smart move. The basic concept has been proposed before (e.g. RAMBUS) but the additional costs of additional components has always been a problem at the low end.
With much of the mass market shifting down to low power portable devices the DIMM memory market is going to suffer so I think there is room for innovation at the top. IBM are obviously not committing to anything other than DDR3 but they have kept their options open.
I recognise your point when it comes to the traditional processor market. However when it comes to the mobile and high power efficiency markets then SOC becomes very important and I believe that ARM will continue to have a real advantage there unless Intel make a big move to open up their fabs.
An Intel closed design SOC, no matter how good it is, will define the capabilities of a device. All that the downstream manufactures will be adding is a case so margins will be very slim. With ARM a company can design their own SOC, built out of IP blocks from multiple sources, and have a chance to differentiate themselves from the competition and charge a higher margin.
If Intel SOCs turn out significantly cheaper than sticking with ARM manufactures will have to go Intel (I'm not sure that is going to happen, smaller processes are getting VERY expensive) otherwise I think they will be reluctant to move.
I doubt a prior art argument will hold up.
OK phone-to-phone gifting is not new but this is phone-to-phone gifting of heavily DRM'ed content from an on-line store without letting the store lose control of the content and its difficult to prior-art (verb ?) apple in that area.
Of course that means that gifting non DRM content by NFC would not be covered as it does not involve downloading the content from a content store.
Somebody should quickly patent exchanging drop-box download links by NFC. Heck you could probably even get it to work without an immediate network connection by generating a unique transaction identifier and then have the giver upload the data when they next get network and the receiver poll until the data is available.
If you look at the original Moore's Law paper the original observation was that the COST per transistor was going down at a geometric rate. Because costs were very roughly per wafer reduced transistor size meant comparable devices cost lest in a new smaller process.
However new fabs and processes are becoming increasingly more expensive than previous generations reducing the cost savings. At some point the wheels are going to come off the cart and it will probably happen due to increased cost before physics limits. Once the increased costs per wafer associated with a smaller feature size matches the increased yield it no longer becomes cost effective to shrink the process.
I would not rule out ARM HPC. ARM should be at least as good as the PowerPC cores in BlueGene.
You would need to add a much better FPU than Neon and might need to tweak the memory interface but it would still be an ARM. Lots of people are thinking about architectures with lots of GPU like vector units driven by a very small lightweight cpu core. Unless you are Intel IBM or AMD then the only sensible choice for the lightweigh core is ARM.
Provided MS don't try too ape the apple approach too closely developers might find it possible to share common code between windows8 and android.
There seem to be tools out there to do cross platform app development its just that apple really don't like them
to be used for the iphone.
Its the apple no-emulators rule that makes it necessary to develop every app twice. A 3 way ecosystem does not necessarily require 3-way app development.
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.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2022
