The truth is that it is hard to round up all the things you need to really have a functioning Raspberry Pi system.
That was my feeling about it as well. The Pi is cute, but it's just a bare-bones implementation of an ARM vendor's reference design. You need to add an awful lot more to turn it into a functional PC-equivalent, and once you glue all that on you're probably going to end up having spent more than just buying an off-the-shelf more-capable reference design implementation. For that reason, although I think it's quite neat, I'm going to wait until it's deployed and we can get a real estimate of what a functional Pi system will require, and cost, before I start going gaga over it.
It does this for a very good architectural reason, it's a whitelist mechanism: you need to get a response saying "yes, we did issue this cert, it's valid", not the blacklist mechanism of CRL "we did revoke those certificates".
Nope, OCSP is blacklist just like CRLs. In fact it was specifically designed to be 100% bug-compatible with CRLs. Attempts were made to turn it into a whitelist mechanism, but were ruled out of scope by the standards group involved, because CRLs were the way you do things, and making OCSP a whitelist would make it more functional than a CRL, which wasn't permitted. So it's just as broken as CRLs, while providing the (dangerous) illusion that it isn't.
That adds insult to injury there... either (A) their security/review practices aren't up to snuff, and they didn't ever detect they'd issued a compromised cert. OR (B) they knew about a problem and hid it for PR or other reasons.
They've been ordained as the official Netherlands CA by the Dutch government. If you're dealing with the government electronically, you have to use them (and they $$really, $$really milk thi$$ for all it$$ worth). Admitting to a problem would be bad for business. Another couple of failures of this magnitude and the Dutch government might even start thinking about revoking their license to print money, or at least issuing licenses to other organisations as well.
Possibly not, the article seems to imply it's a compact reactor rather than an RTG. That's a bit unusual, RTG SNAPs have been used since the 1960s, but compact-reactor SNAPs never got beyond some experimental models in the mid-60s.
It's more like a lightweight non-relational database than anything (I realize that isn't quite right, but it's a reasonable comparison).
It's actually a heavyweight pre-relational (hierarchical) database of the type used in the 1960s before relational databases were invented. Many LDAP servers actually use an RDBMS underneath, with LDAP being an additional mapping layer on top of the standard database (others use key/value stores like Berkeley DB, but again you have to add a hugely-complex mapping layer because LDAP isn't anything like the key/value store that it's using for its storage engine). The only LDAP server I know of that uses a storage engine that's even close to what LDAP does is (supposedly) Novell's Recman (although that may just be marketing propaganda, since they ditched Recman some years ago).
What, you thought "Too big to fail" was only for banks?
In this case the breach appears to have been serious enough that Mozilla have actually pulled the CA's cert. No matter how negligent a CA has been in the past, no browser vendor has ever done this before. Rumors on Mozilla lists are that it was a CA compromise, which would mean that no certs from Diginotar can be trusted at the moment. Whatever it is, it's pretty serious. Again.
Maybe this time the browser vendors will finally be incentivised to fix the PKI mess (CA protection racket) that they've created, although given the outcome of Comodogate (business as usual, nothing to see here, move along) I rather doubt it.
Actually I arrived at "The burrowing effects of dholes and/or bholes in the planetary crust". I don't think Cthulhu had much to do with tectonic movement (mostly because he's asleep at the moment), but thanks for playing.
Next in few mins...Firefox 8 Alpha released and Firefox 9 Preview released... Do we need to clog up the front page with these articles? Gone are the days of version numbers making any sense in FF. We don't report Chrome versions do we?
Shh, not so loud! They're not supposed to know that the Firefox development process switched to:
There are standard graphics pipelines but you will integrate them onto your SOC with direct access to your SDRAM. This removes any standard bus architecture. You may even write your own 3D pipeline.You will probably write your own SDRAM controller. You will add your own peripherals. Why do this rather than plug in standard components? Well if you just stick off the shelf stuff together then how is your product any different from your competitor?
That's exactly the thinking of the device vendors that's got us into the mess we're in now. It's fine if you're a device vendor, it's OK if you're a manufacturer who can ship 100M units with exactly one ARM-based ASIC in it that'll never change in its lifetime, and it's a nightmare if you're doing anything else. For example to do something as basic as add TCP offload on ARM ASICs to our stuff we'd have had to add custom code for every single fscking vendor's bizarro TOE concept. In the end we did it all in software, completely ignoring whatever hardware assist the networking functionality could have had, and offered customers the chance to add custom support for any TOE hardware if they paid for it. So far, zero have taken us up on that. We're doing virtually all the networking in software because that's the only thing that's guaranteed to be the same across all devices.
So it depends on your business model. For the selfish model, "no-one exists but us", it's fine to use a ton of non-standard custom functionality. For a
universalist model, "we're part of an overall ecosystem", you need to be a team player. ARM isn't a team, it's the Balkans, a bunch of stuff that looks more or less the same on the surface but that's deeply divided by endless numbers of ludicrous nitpicky differences that you need a PhD-level depth of knowledge just to understand..
And perhaps most importantly your main system bus is either PCI or something that looks like PCI to software and by accessing the configuration space of that bus you can read the device IDs of everything on it whereas with ARM the software is expected to know the complete hardware setup in advance.
Amen to that. It seems like every vendor's pet ARM variant, and every stepping of every variant, has tons of semi-custom value-add features that they have to add because if they didn't differentiate their variant from everyone else's, you might buy the other guy's device. There's usually no way to tell what's present and what isn't, so you end up creating these complex expert systems that "know" that if you're using vendor X, product Y, stepping Z, then this set of additional functionality is available. Anything that isn't present in your ruleset (i.e. every ARM device that you don't have complete specs for in advance and can test the functionality with) can't be used, and every time there's a new stepping or device release you can't use any of the additional functionality until you've researched it and updated your config.
What the situation reminds me of most is the PC hardware market in the 1980s (everyone does their own oddball hardware and interface) but without the ability to dynamically load a device driver or TSR to talk to it. Unless you develop for one hardware platform/device type and target that in depth, you can never take advantage of all the extra functionality present in most of these devices. Even ARM's primitive attempts at defining HALs are so minimal as to be mostly useless, and half the vendors don't support them anyway.
It beat the market for one whole month? Wow! That puts them in the same class as 50% of high-school finance students!
And cows (researchers marked a fenced area into a grid, assigned a stock to each square, and invested where the cows dropped a cowpat). And chickens (same sort of thing but they invested where chickens pecked up corn).
Show me the three year and I might start to be impressed. If it doesn't go broke in 10 years, then I might take it seriously. A random pick of stocks has a non-negligible chance of beating the market as a whole in a single month.
Extensions are Firefox's drawcard. Without usable extensions, there's very little point in using Firefox. The end user doesn't care who broke their shit, the fact that it is broken will encourage them to consider more "stable" (in terms of platform, not necessarily resistance to crashes) alternatives.
Amen to that. By switching from Firefox to Chromefox, Mozilla have removed any reason to keep using their browser (and introduced numerous reasons to stop using it). For many people the sole thing keeping them with Chromefox (or Firefox if you're still on 3.6 like I am) is the extensions. Without those, I may as well use Chrome, since it's much the same as Chromefox, but with neat extra features like the sandboxing/isolation that Chromefox doesn't have (OK, Chrome has its own set of problems that others have already pointed out, sigh).
I stopped recommending Chromefox to family and friends some time ago because it's become too difficult to support. "Click on... well I dunno, keep clicking around until you find wherever X has moved to this week, and try that". I've been moving some (older) family members to K-Meleon, which despite its somewhat clunky interface gives you most of what Firefox did, and you know that the XYZ menu option will still be in the same place as it was last week. I used to think K-Meleon's less-than-polished UI was a bit of a drawback, but Chromefox has shown me that this can actually be a feature.
It takes my work PC about ten minutes to get to a working desktop.
Are you running on IDE? One good sata spin drive for $40 and you'll be booting in 2 minutes. You don't need SSD to experience normality.
You missed the bit where he said "Work PC". That means it's so loaded with enterprise-grade crap and the need to run eight hundred boot scripts that need to download more crap over a network with a latency worthy of a satellite link that it's going to take 10-15 minutes to boot even with a liquid-nitrogen-cooled i7-EE and any kind of SSD you care to mention.
To get a fast boot, the solution is to not run a metric buttload of crap. My Atom-based netbook (pretty much the slowest PC-grade system you can buy) gets to its XP desktop in under 20 seconds. My work machine running Win7 Enterprise, McAfee,three more pages of enterprise-grade bloat on high-end hardware takes a solid ten minutes minimum before I get a usable desktop, and then another several minutes clicking away the Adobe update dialog, the Java update dialog, the another page or so of additional crap before I can get any work done.
Sisko: What's happening out there? Dax: Gravitational polarization of the quantum vacuum. Sisko: Ahh, gravitational polarization of the quantum vacuum. Dax: Do you know what that is? Sisko: Just a guess here. Technobabble?
Many phones have an anti-sweet spot a mile wide where the 3G signal is strong enough to convince it not to switch, but too weak to actually work well.
I was just about to make the same point, your phone will hunt around endlessly trying to get a vaguely decent 3G signal, dropping in and out and generally being a pain, while you never have any problems with 2G. I have mine locked to 2G only in order to deal with this.
(And to forestall the inevitable "D00d ur phone is teh suck" that this is going to trigger, this is a general problem with many 3G phones. If you're in a strong-signal area you tend not to notice it much, but I'm in a somewhat marginal zone at the intersection of (at least) three cells (lots of hills playing havoc with reception and varying signal paths depending on my exact location), I've tried three different phones and they all spend most of their time hunting around for good connectivity on 3G, but just work on 2G).
Well, except that many many studies have established that it does work.
Well OK, it works, in the same way that deconstructing Mont Blanc with a teaspoon works, eventually, but it's far from the best way to do it. You need to go to experimental psychology, not economics, to deal with issues like this (and lung cancer, and weight problems, and many others). If I wasn't typing this via a borrowed fondle-slab I'd cite some references, but I don't have access to my own machine at the moment. Look up work on behaviour modification, and in particular behavioural risk modification when it's applied to unhealthy living.
There is a thing called an odometer. It's in every car. There's nothing wrong with requiring a car inspection every year and taxing mileage based on the odometer is a much cheaper and simpler and less intrusive way.
And of course no-one would ever dream of winding back an odometer. In conjunction with that, we also don't have considerable numbers of mechanics with experience in fiddling odometers.
Doesn't work (and not just for fuel but for pretty much any indirect charging system). People just grumble, and pay more. When they see the dollars clicking past (or, for things like tobacco, when they see shots of diseased lungs), that's when it has an effect.
So unfortunately while this system is horribly privacy-invasive, you need some form of direct feedback to have an effect on the public. Indirect costs only have a marginal effect on decision-making.
I am concerned about the time frame too. A dip is usually 5 seconds. I would be concerned about much moderate temperatures for much prolonged time period.
Ditto. Liquid nitrogen is great as a publicity stunt, but then you can also pour it onto bare skin without taking any damage (you have to do it right, the evaporating nitrogen forms a protective layer so the liquid never touches your skin and then you angle the limb so it runs off across the gas layer). OTOH how long can you store one of these at 110F and 100% humidity (common in many parts of the world) before the media dies?
Given that their X-Slim series has been around for several years before Intel's "ultrabook" announcement but it is, basically, an "ultrabook". The link above is deliberately to an AMD-powered one just for yucks, but my X340 is pure Core2 and cost all of $390. They're actually damn nice machines, even if Intel is a bit late to the party with their reinvention of them.
The truth is that it is hard to round up all the things you need to really have a functioning Raspberry Pi system.
That was my feeling about it as well. The Pi is cute, but it's just a bare-bones implementation of an ARM vendor's reference design. You need to add an awful lot more to turn it into a functional PC-equivalent, and once you glue all that on you're probably going to end up having spent more than just buying an off-the-shelf more-capable reference design implementation. For that reason, although I think it's quite neat, I'm going to wait until it's deployed and we can get a real estimate of what a functional Pi system will require, and cost, before I start going gaga over it.
It does this for a very good architectural reason, it's a whitelist mechanism: you need to get a response saying "yes, we did issue this cert, it's valid", not the blacklist mechanism of CRL "we did revoke those certificates".
Nope, OCSP is blacklist just like CRLs. In fact it was specifically designed to be 100% bug-compatible with CRLs. Attempts were made to turn it into a whitelist mechanism, but were ruled out of scope by the standards group involved, because CRLs were the way you do things, and making OCSP a whitelist would make it more functional than a CRL, which wasn't permitted. So it's just as broken as CRLs, while providing the (dangerous) illusion that it isn't.
Let me explain. I have been working on Web security now for 19 years.
How cute. I have been working on Web security for 19 years and one day.
Uh, you do realise who you're making fun of there, right? He was helping create the web while you were still in nappies.
Maybe I should tell my browser to just accept certs signed by Bob's SSL Certs and Taco Stand
Or Honest Achmed. I know his cousin Osman, he's OK.
That adds insult to injury there... either (A) their security/review practices aren't up to snuff, and they didn't ever detect they'd issued a compromised cert. OR (B) they knew about a problem and hid it for PR or other reasons.
They've been ordained as the official Netherlands CA by the Dutch government. If you're dealing with the government electronically, you have to use them (and they $$really, $$really milk thi$$ for all it$$ worth). Admitting to a problem would be bad for business. Another couple of failures of this magnitude and the Dutch government might even start thinking about revoking their license to print money, or at least issuing licenses to other organisations as well.
They really haven't been able to do anything other than sell large volume servers since.
A fact that never ceases to amaze me, given that they're running PHUX. I mean the hardware may be nice, but... PHUX? Are people really that desperate?
A more accurate link would have been this.
Possibly not, the article seems to imply it's a compact reactor rather than an RTG. That's a bit unusual, RTG SNAPs have been used since the 1960s, but compact-reactor SNAPs never got beyond some experimental models in the mid-60s.
It's more like a lightweight non-relational database than anything (I realize that isn't quite right, but it's a reasonable comparison).
It's actually a heavyweight pre-relational (hierarchical) database of the type used in the 1960s before relational databases were invented. Many LDAP servers actually use an RDBMS underneath, with LDAP being an additional mapping layer on top of the standard database (others use key/value stores like Berkeley DB, but again you have to add a hugely-complex mapping layer because LDAP isn't anything like the key/value store that it's using for its storage engine). The only LDAP server I know of that uses a storage engine that's even close to what LDAP does is (supposedly) Novell's Recman (although that may just be marketing propaganda, since they ditched Recman some years ago).
What, you thought "Too big to fail" was only for banks?
In this case the breach appears to have been serious enough that Mozilla have actually pulled the CA's cert. No matter how negligent a CA has been in the past, no browser vendor has ever done this before. Rumors on Mozilla lists are that it was a CA compromise, which would mean that no certs from Diginotar can be trusted at the moment. Whatever it is, it's pretty serious. Again.
Maybe this time the browser vendors will finally be incentivised to fix the PKI mess (CA protection racket) that they've created, although given the outcome of Comodogate (business as usual, nothing to see here, move along) I rather doubt it.
And where does tectonic movement come from?
And where does THAT come from?
Ask these enough times and you'll arrive at God.
Actually I arrived at "The burrowing effects of dholes and/or bholes in the planetary crust". I don't think Cthulhu had much to do with tectonic movement (mostly because he's asleep at the moment), but thanks for playing.
Next in few mins...Firefox 8 Alpha released and Firefox 9 Preview released... Do we need to clog up the front page with these articles? Gone are the days of version numbers making any sense in FF. We don't report Chrome versions do we?
Shh, not so loud! They're not supposed to know that the Firefox development process switched to:
after 3.6.
There are standard graphics pipelines but you will integrate them onto your SOC with direct access to your SDRAM. This removes any standard bus architecture. You may even write your own 3D pipeline.You will probably write your own SDRAM controller. You will add your own peripherals. Why do this rather than plug in standard components? Well if you just stick off the shelf stuff together then how is your product any different from your competitor?
That's exactly the thinking of the device vendors that's got us into the mess we're in now. It's fine if you're a device vendor, it's OK if you're a manufacturer who can ship 100M units with exactly one ARM-based ASIC in it that'll never change in its lifetime, and it's a nightmare if you're doing anything else. For example to do something as basic as add TCP offload on ARM ASICs to our stuff we'd have had to add custom code for every single fscking vendor's bizarro TOE concept. In the end we did it all in software, completely ignoring whatever hardware assist the networking functionality could have had, and offered customers the chance to add custom support for any TOE hardware if they paid for it. So far, zero have taken us up on that. We're doing virtually all the networking in software because that's the only thing that's guaranteed to be the same across all devices.
So it depends on your business model. For the selfish model, "no-one exists but us", it's fine to use a ton of non-standard custom functionality. For a universalist model, "we're part of an overall ecosystem", you need to be a team player. ARM isn't a team, it's the Balkans, a bunch of stuff that looks more or less the same on the surface but that's deeply divided by endless numbers of ludicrous nitpicky differences that you need a PhD-level depth of knowledge just to understand..
And perhaps most importantly your main system bus is either PCI or something that looks like PCI to software and by accessing the configuration space of that bus you can read the device IDs of everything on it whereas with ARM the software is expected to know the complete hardware setup in advance.
Amen to that. It seems like every vendor's pet ARM variant, and every stepping of every variant, has tons of semi-custom value-add features that they have to add because if they didn't differentiate their variant from everyone else's, you might buy the other guy's device. There's usually no way to tell what's present and what isn't, so you end up creating these complex expert systems that "know" that if you're using vendor X, product Y, stepping Z, then this set of additional functionality is available. Anything that isn't present in your ruleset (i.e. every ARM device that you don't have complete specs for in advance and can test the functionality with) can't be used, and every time there's a new stepping or device release you can't use any of the additional functionality until you've researched it and updated your config.
What the situation reminds me of most is the PC hardware market in the 1980s (everyone does their own oddball hardware and interface) but without the ability to dynamically load a device driver or TSR to talk to it. Unless you develop for one hardware platform/device type and target that in depth, you can never take advantage of all the extra functionality present in most of these devices. Even ARM's primitive attempts at defining HALs are so minimal as to be mostly useless, and half the vendors don't support them anyway.
It beat the market for one whole month? Wow! That puts them in the same class as 50% of high-school finance students!
And cows (researchers marked a fenced area into a grid, assigned a stock to each square, and invested where the cows dropped a cowpat). And chickens (same sort of thing but they invested where chickens pecked up corn).
Show me the three year and I might start to be impressed. If it doesn't go broke in 10 years, then I might take it seriously. A random pick of stocks has a non-negligible chance of beating the market as a whole in a single month.
What he said.
Extensions are Firefox's drawcard. Without usable extensions, there's very little point in using Firefox. The end user doesn't care who broke their shit, the fact that it is broken will encourage them to consider more "stable" (in terms of platform, not necessarily resistance to crashes) alternatives.
Amen to that. By switching from Firefox to Chromefox, Mozilla have removed any reason to keep using their browser (and introduced numerous reasons to stop using it). For many people the sole thing keeping them with Chromefox (or Firefox if you're still on 3.6 like I am) is the extensions. Without those, I may as well use Chrome, since it's much the same as Chromefox, but with neat extra features like the sandboxing/isolation that Chromefox doesn't have (OK, Chrome has its own set of problems that others have already pointed out, sigh).
I stopped recommending Chromefox to family and friends some time ago because it's become too difficult to support. "Click on... well I dunno, keep clicking around until you find wherever X has moved to this week, and try that". I've been moving some (older) family members to K-Meleon, which despite its somewhat clunky interface gives you most of what Firefox did, and you know that the XYZ menu option will still be in the same place as it was last week. I used to think K-Meleon's less-than-polished UI was a bit of a drawback, but Chromefox has shown me that this can actually be a feature.
It takes my work PC about ten minutes to get to a working desktop.
Are you running on IDE? One good sata spin drive for $40 and you'll be booting in 2 minutes. You don't need SSD to experience normality.
You missed the bit where he said "Work PC". That means it's so loaded with enterprise-grade crap and the need to run eight hundred boot scripts that need to download more crap over a network with a latency worthy of a satellite link that it's going to take 10-15 minutes to boot even with a liquid-nitrogen-cooled i7-EE and any kind of SSD you care to mention.
To get a fast boot, the solution is to not run a metric buttload of crap. My Atom-based netbook (pretty much the slowest PC-grade system you can buy) gets to its XP desktop in under 20 seconds. My work machine running Win7 Enterprise, McAfee,three more pages of enterprise-grade bloat on high-end hardware takes a solid ten minutes minimum before I get a usable desktop, and then another several minutes clicking away the Adobe update dialog, the Java update dialog, the another page or so of additional crap before I can get any work done.
Sisko: What's happening out there?
Dax: Gravitational polarization of the quantum vacuum.
Sisko: Ahh, gravitational polarization of the quantum vacuum.
Dax: Do you know what that is?
Sisko: Just a guess here. Technobabble?
To a Londoner, a map of the UK has London, the M25 and anything outside that marked "here be dragons".
I think you'll find it's actually marked "Hail the Great Beast, destroyer of worlds!".
Many phones have an anti-sweet spot a mile wide where the 3G signal is strong enough to convince it not to switch, but too weak to actually work well.
I was just about to make the same point, your phone will hunt around endlessly trying to get a vaguely decent 3G signal, dropping in and out and generally being a pain, while you never have any problems with 2G. I have mine locked to 2G only in order to deal with this.
(And to forestall the inevitable "D00d ur phone is teh suck" that this is going to trigger, this is a general problem with many 3G phones. If you're in a strong-signal area you tend not to notice it much, but I'm in a somewhat marginal zone at the intersection of (at least) three cells (lots of hills playing havoc with reception and varying signal paths depending on my exact location), I've tried three different phones and they all spend most of their time hunting around for good connectivity on 3G, but just work on 2G).
Well, except that many many studies have established that it does work.
Well OK, it works, in the same way that deconstructing Mont Blanc with a teaspoon works, eventually, but it's far from the best way to do it. You need to go to experimental psychology, not economics, to deal with issues like this (and lung cancer, and weight problems, and many others). If I wasn't typing this via a borrowed fondle-slab I'd cite some references, but I don't have access to my own machine at the moment. Look up work on behaviour modification, and in particular behavioural risk modification when it's applied to unhealthy living.
There is a thing called an odometer. It's in every car. There's nothing wrong with requiring a car inspection every year and taxing mileage based on the odometer is a much cheaper and simpler and less intrusive way.
And of course no-one would ever dream of winding back an odometer. In conjunction with that, we also don't have considerable numbers of mechanics with experience in fiddling odometers.
Tax the fuel.
Doesn't work (and not just for fuel but for pretty much any indirect charging system). People just grumble, and pay more. When they see the dollars clicking past (or, for things like tobacco, when they see shots of diseased lungs), that's when it has an effect.
So unfortunately while this system is horribly privacy-invasive, you need some form of direct feedback to have an effect on the public. Indirect costs only have a marginal effect on decision-making.
It's not just bash google day, of course. A short list of companies that get bashed a lot on slashdot:
Apple
Google
Facebook
MS
Sony
Steam
Oracle
Canonical
Nokia
Motorola
Activision
Comcast
EA
You forgot to include the outfit that makes the Chromefox browser.
I am concerned about the time frame too. A dip is usually 5 seconds. I would be concerned about much moderate temperatures for much prolonged time period.
Ditto. Liquid nitrogen is great as a publicity stunt, but then you can also pour it onto bare skin without taking any damage (you have to do it right, the evaporating nitrogen forms a protective layer so the liquid never touches your skin and then you angle the limb so it runs off across the gas layer). OTOH how long can you store one of these at 110F and 100% humidity (common in many parts of the world) before the media dies?
Given that their X-Slim series has been around for several years before Intel's "ultrabook" announcement but it is, basically, an "ultrabook". The link above is deliberately to an AMD-powered one just for yucks, but my X340 is pure Core2 and cost all of $390. They're actually damn nice machines, even if Intel is a bit late to the party with their reinvention of them.