18 posts • joined Monday 22nd June 2009 19:57 GMT
What a load of marketing tosh
It does a miserable job of saying that you can take your own paid for vyatta license and slap it on any cloud service you like. Vyatta have AWS Marketplace appliances, and the cost for support is about the same if you go annual, or considerably less if you're willing to stump up for a few years.
"Up until now, RackConnect has required an F5 Big-IP or Cisco ASA hardware appliance, but now customers will be able to use vRouter virtual routers instead if they so choose."
And yet for a pittyful 100mbit throughput on the firewall you need to run a fairly large server instance. The ASA appliance will run rings around it.
And on the F5 Big-IP front, load balancing in Vyatta is pittyful, and that's not even scratching the surface of what an F5 can do if you turn the right knobs.
"One important thing, says Engates, is that both the Cloud Networks service and the vRouter service are both IPv6 compliant, so you don't have to mess around with IPv4."
Unless you actually want any users to be able to connect to your services...Don't get me wrong, IPv6 support is nice, but it has so little adoption in this country that having an IPv6 only service is pointless.
.. Because Cisco have never written a proprietary protocol ...
"CUDB node is based on a Distributed Cluster Architecture which guarantees high capacity with an optimal footprint and real time availability.", it says so right on the website!
Looking at RFC5246..
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable. Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV. This was
changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
Which then references http://www.openssl.org/~bodo/tls-cbc.txt
- Not a new attack, but the method of injecting chosen plaintext is
- Block ciphers are affected, I'm guessing the venerable RC4 algorithm isn't
Re AC 06:11
Operas update servers are behind a load balancer which is currently only TLSv1 and not reneg patch, which has been a big source of frustration to the opera security team.
If I'm right at guessing which load balancer they refer to, then they've just produced a new release with TLSv1.2 - suspect it'll need some testing before deployment
Generally, on this subject, hmmm...
Well I can't see the face of the world changing, but it is concerning.
- The packet capture (In reality) is difficult for someone that isn't in direct control of the network (Who could therefore probably do nasty things in much easier ways).
In the real world, I suspect it'll be considerably easier to for mass fraud to find yourself a nice drive-by zero day, drop a trojan and profit.
Re Gordon 10
"Are PI saying that phrases are identifiable AFTER skypes encryption is added?
If the encryption is a integral part of the codec then this is a major fail for skype.
If PI's tests were based on a pre-encrypted stream it seems like a non-argument."
I think what they're trying to say is that because a variable bitrate compression algorithm is used, you'll get variable bitrates of the ciphertext (ciphervoice?). you can then analyst when it was at low levels (Quiet) vs high rates (speaking) and try and use the length of the words to identify phrases.
I don't believe codecs generally used by more standard compliant SIP solutions tend to use variable bitrate, eg g.711 certainly doesn't, so if a good crypto wrapper (Eg TLS with a decent cipher) is applied around this codec then the same sort of attack wouldn't be possible
Interesting attack vector.
All very well quoting manufacturer original prices, but with laserjets you can buy compat cartridges without risking your print heads.
If you want to bring your prices down, rescue an old HP laserjet before it hits landfill (Laserjet 6, Laserjet 4000). They run forever and the toner is silly cheap
@ Matthew 3 ...falling victim to the trolls #
I'm fairly sure most linux distros still ask you for a root password and then insist on creating a standard user account as well. (Debian for a start)
Some of the more cuddly distros don't operate in that way, requesting your user password again when you try to do any actions requiring root access, but it is at least a positive action you need to take. (Windows 7 has UAC of course, which will give you a yes/no)
Kinda makes sense
Given basically everything is widescreen now, this layout does make better use of screen real-estate.
I absolutely hate widescreens, they're possibly the biggest annoyance of my new laptop, but try and find a 4:3 screen or laptop now...
You can install almost all apps without root access. If you can't get something into the marketplace, its not locked down to app store purchases only - you just download the installer via the web browser.
It does allow a wide variety of operating system hacks, and allow wireless teather, but jailbreaking isn't key to "free, unrestricted" use of the phone, its there by design.
Oh come on, yes the operator gets final say on what's on the stock image. no different from hundreds of other phones. You'll get the images in a few weeks no doubt.
What's really different is how modable the android OS is once you jailbreak. There is a huge difference with what you can do (Get pirate apps vs completely written parts of the OS, different schedulers, etc), and no doubt long after apple have lost interest in the hardware your phone is running, there will still be mods coming out for my G1. And once its rooted, you don't have to play a cat and mouse game with google to keep it routed. Google couldn't give a rats ass if your phone is running a stock image or not.
Cyanogen mod has made my G1 a totally different phone.
Hell, you need to jailbreak your iPhone to run two applications at once!
Seems a very reasonably chip still
Lets face it, its going to be very unusual workloads that will tax 4 cores, let alone take advantage of the 8 cores you get with hyperthreading. (Database servers, Well loaded Web Server - the only desktop task i can think of would be video rendering)
It seems these are likely to be dual rather than triple channel DDR3 - guess we'll have to wait for benchmarks to see the performance impact there.
If its a bit cheaper than the I7, it could well be a winner. I've been holding off on upgrading (Lets face it, core2duo / quad have been looking like old designs for a while now - how long have AMD been free of the front side bus?)
With most films (Example: Polaroid 600 series, for which "Shop stock" has pretty much totally disappeared) you expect the lovers of the film to "clear the shelves".
I doubt we'll see the same with Kodachrome. Because of the specialist process which only Dwaynes offer (IE to process my kodachrome, i need to ship it to Switzerland, who then forward it to America, who then post it back to me), the film is utterly useless the moment they shut down production. (And can't be cross processed, you might manage a black and white image out of it).
Shelf stock might run out, but there is LOADS of this stuff around and about (Small camera dealers, peoples film draws at home - both the still used and long forgotten variety). I forsee a mountain of the unprocessable film come 2011.
Shame to see it go. BECAUSE of my IT background I still shoot film. I sit in front of a computer all day, no need for me to sit behind another one when I go out to take some pictures. I love film, but this is an obvious one to kill off, the process is really quite complex and its a month before you see your slides back. I doubt many people will give up shooting film all together, they'll simply move to a more standard slide process, which can be processed everywhere and is made by more manufacturers (Actually, only 2 thinking about it)