I've gotten 20 fps for 1280x1024 3D graphics -- over a 2 Mbit connection.
On the other hand for usable browsing and general desktop sessions NX doesn't need close to 2Mbit, it works well for me at 56kbit. So it's horses for courses, I guess.
It's not the VNC protocol that gives you your good 3D performance, it's the architecture of VirtualGL. I don't think there's a good reason VirtualGL couldn't be made to work with NX as well as VNC.
The future probably belongs to SPICE, which redhat (a company who do know how to develop open source code) are creating for remote access to virtualised systems.
That argument applies to encryption algorithm/protocol design, not specific implementations.
The OpenBSD IPSEC has to use the same constants for its AES as every other IPSEC implementation, or you don't have a backdoor you have a product that doesn't work.
Yes, but they typically hide this in an iFrame -- which to the vast majority of users amounts to exactly the same thing as entering their password into the retailer's site.
My bank does at least allow me to customise the greeting it shows in the "SecureCode" iFrame. Since a 3rd party wouldn't know my greeting, it does give me some assurance that I'm entering my code into MasterCard's form and not some phisher's.
OK, reasonable points. But why do we put up with basing the scheduler on various heuristics anyway. The kernel might need to mind read, but users of the system know what they want (and more importantly so do those configuring the distro).
There seem to be two sensible lines of attack which avoid mind reading:
1) Applications are given reliable ways to tell the kernel what performance they need. Every packager knows that mplayer is latency critical and needs to avoid CPU starvation, and that make wants thoughput, but is a batch load. So why is the scheduler guessing?
2) Feedback. Does the scheduler know when it's getting things right? Does mplayer have a way of indicating that it's dropping frames? The desktop environment knows which window the user has in focus, does the kernel? If you can measure what effect you're having (and you've been told what's wanted) then scheduling without mind reading gets a whole lot easier.
Getting an algorithm to schedule CPU time while best meeting the demands of many processes isn't easy, but I don't see a need for guesswork in the requirements.
Ironically, one of those, Margaret Thatcher, is not a graduate of the University of Oxford. She was an undergraduate at Oxford, but dropped out without a degree. But plenty of other British prime minsters did (David Cameron, Tony Blair, Harold Wilson, Edward Heath, Alec Douglas-Hume, Harold Macmillan, Anthony Eden and Clement Attlee, just since WW2).
The grooming in question is not so much for politicians, but for the civil servants who actually do the running of the country, and who you don't recognise the names of or get to vote for. PPE (politics, philosophy and economics) is a course specifically designed to be good preparation for a career in Whitehall.
You misunderstood the GP. You just need to persuade enough _other_ people to register for organ donership, possibly by suggesting that you'd done it yourself and it was no big deal. This would be enough to increase supply and reduce illicit demand. Then your own organs are safe, and your family can be comforted by the knowledge that they'll be eaten by worms.
Anyway, I personally don't see what the fuss is about. Just last month, when changing doctors, I registered as an organ doner myself. I don't have any religious beliefs that my body will travel to the "other side", so why not let society benefit.
All of that subject to successfully avoiding Oracle's lawyers, of course.
You do know that Google are being sued by Oracle over Android's java-like Dalvik VM. If that doesn't play out well then non SunOracle Java is pretty dead.
you'll suggest is that the disc is full of 500GB of random data, rather than password encrypted data. That fails the "beyond reasonable doubt" laugh test.
At work I have piles of disks full of random data. We have data security obligations, and all old HDDs get overwritten with random data before disposal. This is not unusual practice (though some I know pay to have them physically shredded). We do this to avoid prosecution under data protection law for failing to keep personal data secure, or to delete it after its business use is finished.
In addition, on occasion, I use the linux command sfill to overwrite free space in filesystems. This is to ensure that the contents of deleted files don't remain sitting around on the disk.
In short, there is plenty of random data (well pseudo random to be honest) on HDDs I have, without it being used to hold encrypted filesystems -- though I do have an encrypted filesystem to store financial records etc.
Absolutely. I don't understand why do dual-stack and NAT44 instead of giving customers IPv6 and NAT64.
I assume this is because the problem isn't just all those web servers on IPv4 addresses, but a significant number of end user applications that are not IPv6 aware. Unfortunately, if we allow them to avoid upgrading with NAT44 then we can confidently predict that apps won't get updated and you'll never be able to switch it off. It's human nature not to fix the problem until forced to.
Microsoft (at least MS Research) have been doing interesting work in capturing the traces of javascript execution from real websites, with the intention of producing realistic benchmarks. It's a sensible approach though it only captures the type of JS web developers are prepared to use on the web right now (i.e. in an environment which includes substantial IE6 rather than made up of the best JS engines available). A sensible benchmark will also need to take account of the kinds of apps which are now written in flash (or just not deployed in browsers), but would use JS if it were fast enough.
When i was young it was considered rude to take sweets from the local shops without paying, yet some proportion of the shops stock was stolen. Shopkeepers have reacted (and technology has moved on) and it is now standard for shops to be recording CCTV, as well as implementing policies such limiting the number of school age kids in the shop at one time. This is not without privacy implications, but society has in general accepted it.
Copyright infringement is not an exact analogy with theft, as is regularly pointed out on/. , but there are some valid comparisons to be made.
I'm not at all convinced that society in general agrees that you have fundamental rights in the are of network packet inspection and online anonymity. I'm sorry if that's news to you.
For myself, I'm not a fan of DRM: it gets in the way of what I consider legitimate use of content I pay for (such as playing it on a variety of hardware, including my linux machines, and being able to access it in the future), and I'm not prepared to pay for content which is locked behind DRM. This does limit my access to a variety of culture in digital form, but at least for now, it's a limitation I can live with. But that doesn't mean I believe I should be given something for nothing, or that just because I can now pay for clean mp3s, that entitles me to spread them as widely as I like.
Unless you have an encoder license covering x264 then MPEG-LA still claim you are violating their patents if you use x264 to encode. MPEG-LA don't give out encoder licenses to end users (not even if you offer to pay them), but only to encoder suppliers. Even though I have a licensed H.264 decoder supplied with my OS, it is only licensed to play content created with a licensed encoder. I don't have, and can't obtain, a license to play x264 encoded video. So the MPEG-LA still claim I am violating their patents if I play something you encoded. Both of us _could_ get sued.
People who want "free as in open source", are not usually interested in free as in I can download some code but don't have patent licenses for it. This announcement has done nothing, nothing at all, to obviate the need to encoder and decoder licenses, this was only about streaming licenses -- yet another license you needed on top of encoder licenses and decoder licenses.
So x264 is maybe useful for "encoder manufacturers"; they can use its code in their products, if they can find a way to do so under the terms of the GPL[0]. Google use x264 based tools to encode youtube videos, and they have registered themselves as an encoder supplier to get the patent license (even though they only supply themselves). Since they don't distribute the encoder they create, they don't have to comply with the patent clauses in the GPL. Google are about the only people to legally benefit from x264, the rest of us don't have the size/funds for that option.
You can take the view that you don't care about infringing patents and ignore the MPEG-LA (fine, but in which case this announcement doesn't matter to you), or you do care (in which case this announcement still doesn't allow you to use open source H.264 codecs). There is *nothing* in this announcement for Open Source video users.
[0] The GPL, which x264 claims it is licensed under says: "if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
The full Java SE ran at full speed on desktop computers that had a fraction of the computational power of today's mobile phones (think about 75 MHz Pentiums with 16 MB RAM). The cheapest smartphone of today could run Java SE with no problems. Except for the fact that many desktop-oriented APIs would make little sense on a phone (e.g. Swing UIs). SWT was never part of Java SE.
Oops, I did mean Swing rather than SWT.
Don't think "full java" has remained constant though. Java6 wouldn't get out of bed for 16Mb RAM. And remember it was the performance on pre-Ghz machines which gave Java its reputation for being dog slow.
Well the Apache Harmony project have never made a stable release, so they've never got to stage where they have any users to sue[*], and without access to Oracle/Sun's Technology Compatibility Kit they probably won't.
If they could get certified as a conforming implementation then they would covered under the patent grant.
[*] I don't know of anyone actually using Harmony code for real -- apart from Google who use some of the class libraries on Android!
The full Java SE is not appropriate for a mobile phone, far to heavyweight and full of APIs like the AWT, SWT etc.
Sun also produced Java ME for mobile use which they charged phone makers to license. Sun (now Oracle) only open sourced, and gave patent grants for, the desktop oriented Standard Edition where they didn't have any revenue anyway. They were careful in the licensing not to allow a free Mobile Edition which would threaten their mobile revenue.
This was a significant problem for Apache's Harmony project. They couldn't accept Sun's restrictions on use so Sun wouldn't license them as a conforming implementation (despite them having done the work to pass the tests).
In practice, the terms of the patent grant mean that while the Java Virtual Machine implementation is free software and can be altered (such as RedHat's work porting the OpenJDK to other architectures). Java as a whole doesn't give you the freedom to make changes to the standard libraries (even if you do call it something else); it's hard to consider it free software.
It's all particularly annoying since, post-iPhone, Java ME has slipped into irrelevancy. There's no particularly strong reason why Google based the Android environment (dalvik) on the java language (though not on the JVM nor standard libs) rather than something else. The availability of Harmony code for reuse, existing tooling in the form of Eclipse, developer familiarity, and substantial internal use of java at Google probably played a part. Interoperability with other mobile java certainly didn't.
Sure, there is a somewhat fuzzy edge between what you consider a fair price and the price at which you're not interested. Also, humans are not particularly rational beings. Combine the two and auctions can easily lead to someone paying over the odds.
You decided that $50 was your top price, but see that someone has bid $50.01. That's not worth losing over; you bid $50.05 (or whatever eBays minimum increment is); your competitor ups hers. This keeps on going for a few rounds (after all if it's worth $50 it's probably worth 20-30c more). But by now you've become emotionally involved: you've invested effort in making these bids, if you back down you'll have the negative feeling of having lost, rather than the neutral feeling of some item costing more than you wanted to pay. Before you started out you might have thought it was worth $50 but not $52. With little time to respond, and in the competitive auction environment, you don't make the same judgements and keep bidding one of you finally wins at $61. It then turns out you could have bought the item from another fixed priced seller for $55.
You see this a lot on eBay; it's good for the seller, but not for buyers. So much more rational to take advantage of eBay's Vickrey auction style proxy bidding. Bid your maximum and if you win you only pay for one increment above the 2nd choice person. Don't choose a round number, if the item is worth about $50 but not $52, pick a random number somewhere in between, say $50.73. If you win, great, if not you don't feel too bad about it -- it's not like the 50 vs 50.01, you've already given yourself a little margin.
In theory this is a good strategy but it doesn't take account of the pool of irrational eBayers, and the outright cheats. If you leave your best bid up a long while before the end, a couple of bad things might happen:
1) shill bidders (the seller, or someone in league with them using another account) may come and bid up the auction so you pay more than you otherwise would. They may even bid past your limit thus finding out your maximum, then cancel the bid and bid to just below your maximum. EBay don't allow it, but it happens where they don't spot it.
2) Someone may come and think it's worth $45, bid that and see it doesn't win. Reason as you did, and bid a little more, then a little more again. Now they're the one's getting emotionally involved and keep bidding thinking "just one more and I might be in the lead", eventually bidding themselves up past you even if they wouldn't have considered the item worth it.
Best to avoid this entirely, bid what you think's a fair price close to the end of auction. If others have done the same, and bid their maximum (you know, just like eBay suggest in to) then they won't be unhappy.
Hence snipping. Perfectly rational, and only a disadvantage to buyers who, for some reason, like to bid up incrementally instead of using the eBay proxy bid system.
I really can't see why buyers complain so much about it. Of course it's not in seller's interest, they benefit when people get carried away bidding.
Your description sounds about right. But, by using storage as your proxy for all IT cost you are putting perverse incentives for people to use less storage than is right for their business need (or to avoid using central storage, where it can be managed and backed up, and put their stuff on their own external HDDs).
I think a per person overhead charge, plus a storage charged at closer to cost is likely to work out better.
Conversely, if you convinced your management to contract externally for storage, everyone else might find their per GB cost rise, since the fixed costs would be static.
Right, so this is the exactly what a rational department manager should be doing.
Incidentally, I started looking into running my own departmental IMAP server yesterday to avoid much smaller charges of about $30/Gb/year for email archiving from central computing services.
But the TFA is not necessarily correct (in this case your quote from Monty). Some of the newer DSLRs (certainly Olympus and I think Nikon) are recording HD video in MJPEG.
As the summary says, this is the first trough CSP using salt as the collection medium - not the first to use salt at all (it's typical to use salt for heat storage). Other parabolic trough systems use oil in the collector tubes.
But now it's only a freak occasion you're worried about, you could do what is _already_ done to deal with exceptional problems in power generation and give larger industrial customers a discount for the possibility that they'd have to lose a day or two's operation when that happens. This turns out to be cheaper than keeping unnecessary generation capacity on standby.
By adjusting these discounts you can create a significant elasticity in the demand. If, in the future, we move some proportion of travel to use rechargeable electric vehicles, then there will also be a degree of flexibility in the rate these need recharging which can also be exploited by adjusting price.
No need for the lights to go off and leave you in the dark with your fear of zombies. Put your imagination to better use.
Both the French and Californian plants were solar tower type where the mirrors all concentrate the sun on to one point (from where heat energy can be extracted with molten salt).
The article is about a parabolic trough system where rows of mirrors with parabolic X-section concentrate the sun onto a pipe running along the focus point. This is easier to construct and scale than the towers you point to and is already deployed more widely. Previous trough systems have heated oil in the pipes then transferred the heat to salts for storage (then again to water to run a turbine).
The advance here is to avoid this oil to salt transfer, while the slashdot headline is inaccurate (shock horror), this something new and a genuine step forward.
Er, I ingested more than 400mg of NaCl on my lunch today.
True, my government's recommendation is to ingest less that 6000mg per day, but it's manufacturers of processed food not renewable energy who threaten that.
Not that these heat storage systems use Sodium Chloride, I think they actually use Nitrates (i.e. fertilizer).
DNSSEC has always seemed to me as being overly complex for what it is actually doing (I'd say the same thing about the DNS protocol in general).
...
When I read about DNSCurve it seems much simpler in achieving similar goals.
I read comments like this quite regularly. Actually, DNSCurve does something pretty different from DNSSEC.
DNSCurve encrypts communication between DNS clients and servers (or between DNS servers). Like with HTTPS or IMAPS, this means someone between you and your DNS provider can't see what you're looking up, or MITM you to change results.
But DNSCurve does nothing to guarantee you're getting a good answer. You have to trust your DNS provider: both that they are trustworthy and that they have their server secured properly. You also have to trust any recursive DNS lookups your provider does and each of their intentions and configurations.
DNSSEC, on the other hand, signs the records that you're returned (like PGP signed emails) but it doesn't encrypt the traffic. Someone could still snoop on your DNS traffic and see what you're looking up, but with the hierarchical set of signed records no-one except the authoritative name server can change the answer. Not your DNS provider nor any other resolvers they depend on.
It's the difference between getting your email over IMAPS and having it PGP signed -- you don't need to trust every intermediary. Yet I don't see anyone saying, "since we can now to SMTP and IMAP over SSL we don't need PGP or SMIME."
You could certainly use both: DNSCurve to provide encryption, so that no-one but your DNS provider knows what you're looking up, and DNSSEC so you know it is actually a valid record.
Slashdot Mirror
I've gotten 20 fps for 1280x1024 3D graphics -- over a 2 Mbit connection.
On the other hand for usable browsing and general desktop sessions NX doesn't need close to 2Mbit, it works well for me at 56kbit. So it's horses for courses, I guess.
It's not the VNC protocol that gives you your good 3D performance, it's the architecture of VirtualGL. I don't think there's a good reason VirtualGL couldn't be made to work with NX as well as VNC.
The future probably belongs to SPICE, which redhat (a company who do know how to develop open source code) are creating for remote access to virtualised systems.
That argument applies to encryption algorithm/protocol design, not specific implementations.
The OpenBSD IPSEC has to use the same constants for its AES as every other IPSEC implementation, or you don't have a backdoor you have a product that doesn't work.
Yes, but they typically hide this in an iFrame -- which to the vast majority of users amounts to exactly the same thing as entering their password into the retailer's site.
My bank does at least allow me to customise the greeting it shows in the "SecureCode" iFrame. Since a 3rd party wouldn't know my greeting, it does give me some assurance that I'm entering my code into MasterCard's form and not some phisher's.
OK, reasonable points. But why do we put up with basing the scheduler on various heuristics anyway. The kernel might need to mind read, but users of the system know what they want (and more importantly so do those configuring the distro).
There seem to be two sensible lines of attack which avoid mind reading:
1) Applications are given reliable ways to tell the kernel what performance they need. Every packager knows that mplayer is latency critical and needs to avoid CPU starvation, and that make wants thoughput, but is a batch load. So why is the scheduler guessing?
2) Feedback. Does the scheduler know when it's getting things right? Does mplayer have a way of indicating that it's dropping frames? The desktop environment knows which window the user has in focus, does the kernel? If you can measure what effect you're having (and you've been told what's wanted) then scheduling without mind reading gets a whole lot easier.
Getting an algorithm to schedule CPU time while best meeting the demands of many processes isn't easy, but I don't see a need for guesswork in the requirements.
Ironically, one of those, Margaret Thatcher, is not a graduate of the University of Oxford. She was an undergraduate at Oxford, but dropped out without a degree. But plenty of other British prime minsters did (David Cameron, Tony Blair, Harold Wilson, Edward Heath, Alec Douglas-Hume, Harold Macmillan, Anthony Eden and Clement Attlee, just since WW2).
The grooming in question is not so much for politicians, but for the civil servants who actually do the running of the country, and who you don't recognise the names of or get to vote for. PPE (politics, philosophy and economics) is a course specifically designed to be good preparation for a career in Whitehall.
You misunderstood the GP. You just need to persuade enough _other_ people to register for organ donership, possibly by suggesting that you'd done it yourself and it was no big deal. This would be enough to increase supply and reduce illicit demand. Then your own organs are safe, and your family can be comforted by the knowledge that they'll be eaten by worms.
Anyway, I personally don't see what the fuss is about. Just last month, when changing doctors, I registered as an organ doner myself. I don't have any religious beliefs that my body will travel to the "other side", so why not let society benefit.
All of that subject to successfully avoiding Oracle's lawyers, of course.
You do know that Google are being sued by Oracle over Android's java-like Dalvik VM. If that doesn't play out well then non SunOracle Java is pretty dead.
you'll suggest is that the disc is full of 500GB of random data, rather than password encrypted data. That fails the "beyond reasonable doubt" laugh test.
At work I have piles of disks full of random data. We have data security obligations, and all old HDDs get overwritten with random data before disposal. This is not unusual practice (though some I know pay to have them physically shredded). We do this to avoid prosecution under data protection law for failing to keep personal data secure, or to delete it after its business use is finished.
In addition, on occasion, I use the linux command sfill to overwrite free space in filesystems. This is to ensure that the contents of deleted files don't remain sitting around on the disk.
In short, there is plenty of random data (well pseudo random to be honest) on HDDs I have, without it being used to hold encrypted filesystems -- though I do have an encrypted filesystem to store financial records etc.
Absolutely. I don't understand why do dual-stack and NAT44 instead of giving customers IPv6 and NAT64.
I assume this is because the problem isn't just all those web servers on IPv4 addresses, but a significant number of end user applications that are not IPv6 aware. Unfortunately, if we allow them to avoid upgrading with NAT44 then we can confidently predict that apps won't get updated and you'll never be able to switch it off. It's human nature not to fix the problem until forced to.
Microsoft (at least MS Research) have been doing interesting work in capturing the traces of javascript execution from real websites, with the intention of producing realistic benchmarks. It's a sensible approach though it only captures the type of JS web developers are prepared to use on the web right now (i.e. in an environment which includes substantial IE6 rather than made up of the best JS engines available). A sensible benchmark will also need to take account of the kinds of apps which are now written in flash (or just not deployed in browsers), but would use JS if it were fast enough.
The best link I can find right now is to a recent video presentation: http://research.microsoft.com/apps/video/dl.aspx?id=136780
They do note that Mozilla is also supporting this effort. Hopefully this kind of workload will be part of future benchmarks.
When i was young it was considered rude to take sweets from the local shops without paying, yet some proportion of the shops stock was stolen. Shopkeepers have reacted (and technology has moved on) and it is now standard for shops to be recording CCTV, as well as implementing policies such limiting the number of school age kids in the shop at one time. This is not without privacy implications, but society has in general accepted it.
Copyright infringement is not an exact analogy with theft, as is regularly pointed out on /. , but there are some valid comparisons to be made.
I'm not at all convinced that society in general agrees that you have fundamental rights in the are of network packet inspection and online anonymity. I'm sorry if that's news to you.
For myself, I'm not a fan of DRM: it gets in the way of what I consider legitimate use of content I pay for (such as playing it on a variety of hardware, including my linux machines, and being able to access it in the future), and I'm not prepared to pay for content which is locked behind DRM. This does limit my access to a variety of culture in digital form, but at least for now, it's a limitation I can live with. But that doesn't mean I believe I should be given something for nothing, or that just because I can now pay for clean mp3s, that entitles me to spread them as widely as I like.
Only in some 1990s unix-like world where the manual pages are comprehensive, up to date and reasonably well organised.
As time goes by this applies to recent linux tools less and less. With many projects the only replacement seems to be googling for blog postings.
Now that's an idea. Let FYR Macedonia change name to North Macedonia, it's less of a mouthful and geographically accurate.
Somehow, though, I have my doubts that the Greeks will take to it.
Not really.
Unless you have an encoder license covering x264 then MPEG-LA still claim you are violating their patents if you use x264 to encode. MPEG-LA don't give out encoder licenses to end users (not even if you offer to pay them), but only to encoder suppliers. Even though I have a licensed H.264 decoder supplied with my OS, it is only licensed to play content created with a licensed encoder. I don't have, and can't obtain, a license to play x264 encoded video. So the MPEG-LA still claim I am violating their patents if I play something you encoded. Both of us _could_ get sued.
People who want "free as in open source", are not usually interested in free as in I can download some code but don't have patent licenses for it. This announcement has done nothing, nothing at all, to obviate the need to encoder and decoder licenses, this was only about streaming licenses -- yet another license you needed on top of encoder licenses and decoder licenses.
So x264 is maybe useful for "encoder manufacturers"; they can use its code in their products, if they can find a way to do so under the terms of the GPL[0]. Google use x264 based tools to encode youtube videos, and they have registered themselves as an encoder supplier to get the patent license (even though they only supply themselves). Since they don't distribute the encoder they create, they don't have to comply with the patent clauses in the GPL. Google are about the only people to legally benefit from x264, the rest of us don't have the size/funds for that option.
You can take the view that you don't care about infringing patents and ignore the MPEG-LA (fine, but in which case this announcement doesn't matter to you), or you do care (in which case this announcement still doesn't allow you to use open source H.264 codecs). There is *nothing* in this announcement for Open Source video users.
[0] The GPL, which x264 claims it is licensed under says: "if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
The full Java SE ran at full speed on desktop computers that had a fraction of the computational power of today's mobile phones (think about 75 MHz Pentiums with 16 MB RAM). The cheapest smartphone of today could run Java SE with no problems. Except for the fact that many desktop-oriented APIs would make little sense on a phone (e.g. Swing UIs). SWT was never part of Java SE.
Oops, I did mean Swing rather than SWT.
Don't think "full java" has remained constant though. Java6 wouldn't get out of bed for 16Mb RAM. And remember it was the performance on pre-Ghz machines which gave Java its reputation for being dog slow.
Well the Apache Harmony project have never made a stable release, so they've never got to stage where they have any users to sue[*], and without access to Oracle/Sun's Technology Compatibility Kit they probably won't.
If they could get certified as a conforming implementation then they would covered under the patent grant.
[*] I don't know of anyone actually using Harmony code for real -- apart from Google who use some of the class libraries on Android!
The full Java SE is not appropriate for a mobile phone, far to heavyweight and full of APIs like the AWT, SWT etc.
Sun also produced Java ME for mobile use which they charged phone makers to license. Sun (now Oracle) only open sourced, and gave patent grants for, the desktop oriented Standard Edition where they didn't have any revenue anyway. They were careful in the licensing not to allow a free Mobile Edition which would threaten their mobile revenue.
This was a significant problem for Apache's Harmony project. They couldn't accept Sun's restrictions on use so Sun wouldn't license them as a conforming implementation (despite them having done the work to pass the tests).
In practice, the terms of the patent grant mean that while the Java Virtual Machine implementation is free software and can be altered (such as RedHat's work porting the OpenJDK to other architectures). Java as a whole doesn't give you the freedom to make changes to the standard libraries (even if you do call it something else); it's hard to consider it free software.
It's all particularly annoying since, post-iPhone, Java ME has slipped into irrelevancy. There's no particularly strong reason why Google based the Android environment (dalvik) on the java language (though not on the JVM nor standard libs) rather than something else. The availability of Harmony code for reuse, existing tooling in the form of Eclipse, developer familiarity, and substantial internal use of java at Google probably played a part. Interoperability with other mobile java certainly didn't.
Sure, there is a somewhat fuzzy edge between what you consider a fair price and the price at which you're not interested. Also, humans are not particularly rational beings. Combine the two and auctions can easily lead to someone paying over the odds.
You decided that $50 was your top price, but see that someone has bid $50.01. That's not worth losing over; you bid $50.05 (or whatever eBays minimum increment is); your competitor ups hers. This keeps on going for a few rounds (after all if it's worth $50 it's probably worth 20-30c more). But by now you've become emotionally involved: you've invested effort in making these bids, if you back down you'll have the negative feeling of having lost, rather than the neutral feeling of some item costing more than you wanted to pay. Before you started out you might have thought it was worth $50 but not $52. With little time to respond, and in the competitive auction environment, you don't make the same judgements and keep bidding one of you finally wins at $61. It then turns out you could have bought the item from another fixed priced seller for $55.
You see this a lot on eBay; it's good for the seller, but not for buyers. So much more rational to take advantage of eBay's Vickrey auction style proxy bidding. Bid your maximum and if you win you only pay for one increment above the 2nd choice person. Don't choose a round number, if the item is worth about $50 but not $52, pick a random number somewhere in between, say $50.73. If you win, great, if not you don't feel too bad about it -- it's not like the 50 vs 50.01, you've already given yourself a little margin.
In theory this is a good strategy but it doesn't take account of the pool of irrational eBayers, and the outright cheats. If you leave your best bid up a long while before the end, a couple of bad things might happen:
1) shill bidders (the seller, or someone in league with them using another account) may come and bid up the auction so you pay more than you otherwise would. They may even bid past your limit thus finding out your maximum, then cancel the bid and bid to just below your maximum. EBay don't allow it, but it happens where they don't spot it.
2) Someone may come and think it's worth $45, bid that and see it doesn't win. Reason as you did, and bid a little more, then a little more again. Now they're the one's getting emotionally involved and keep bidding thinking "just one more and I might be in the lead", eventually bidding themselves up past you even if they wouldn't have considered the item worth it.
Best to avoid this entirely, bid what you think's a fair price close to the end of auction. If others have done the same, and bid their maximum (you know, just like eBay suggest in to) then they won't be unhappy.
Hence snipping. Perfectly rational, and only a disadvantage to buyers who, for some reason, like to bid up incrementally instead of using the eBay proxy bid system.
I really can't see why buyers complain so much about it. Of course it's not in seller's interest, they benefit when people get carried away bidding.
Your description sounds about right. But, by using storage as your proxy for all IT cost you are putting perverse incentives for people to use less storage than is right for their business need (or to avoid using central storage, where it can be managed and backed up, and put their stuff on their own external HDDs).
I think a per person overhead charge, plus a storage charged at closer to cost is likely to work out better.
Conversely, if you convinced your management to contract externally for storage, everyone else might find their per GB cost rise, since the fixed costs would be static.
Right, so this is the exactly what a rational department manager should be doing.
Incidentally, I started looking into running my own departmental IMAP server yesterday to avoid much smaller charges of about $30/Gb/year for email archiving from central computing services.
But the TFA is not necessarily correct (in this case your quote from Monty). Some of the newer DSLRs (certainly Olympus and I think Nikon) are recording HD video in MJPEG.
As the summary says, this is the first trough CSP using salt as the collection medium - not the first to use salt at all (it's typical to use salt for heat storage). Other parabolic trough systems use oil in the collector tubes.
But now it's only a freak occasion you're worried about, you could do what is _already_ done to deal with exceptional problems in power generation and give larger industrial customers a discount for the possibility that they'd have to lose a day or two's operation when that happens. This turns out to be cheaper than keeping unnecessary generation capacity on standby.
By adjusting these discounts you can create a significant elasticity in the demand. If, in the future, we move some proportion of travel to use rechargeable electric vehicles, then there will also be a degree of flexibility in the rate these need recharging which can also be exploited by adjusting price.
No need for the lights to go off and leave you in the dark with your fear of zombies. Put your imagination to better use.
Both the French and Californian plants were solar tower type where the mirrors all concentrate the sun on to one point (from where heat energy can be extracted with molten salt).
The article is about a parabolic trough system where rows of mirrors with parabolic X-section concentrate the sun onto a pipe running along the focus point. This is easier to construct and scale than the towers you point to and is already deployed more widely. Previous trough systems have heated oil in the pipes then transferred the heat to salts for storage (then again to water to run a turbine).
The advance here is to avoid this oil to salt transfer, while the slashdot headline is inaccurate (shock horror), this something new and a genuine step forward.
Er, I ingested more than 400mg of NaCl on my lunch today.
True, my government's recommendation is to ingest less that 6000mg per day, but it's manufacturers of processed food not renewable energy who threaten that.
Not that these heat storage systems use Sodium Chloride, I think they actually use Nitrates (i.e. fertilizer).
DNSSEC has always seemed to me as being overly complex for what it is actually doing (I'd say the same thing about the DNS protocol in general).
...
When I read about DNSCurve it seems much simpler in achieving similar goals.
I read comments like this quite regularly. Actually, DNSCurve does something pretty different from DNSSEC.
DNSCurve encrypts communication between DNS clients and servers (or between DNS servers). Like with HTTPS or IMAPS, this means someone between you and your DNS provider can't see what you're looking up, or MITM you to change results.
But DNSCurve does nothing to guarantee you're getting a good answer. You have to trust your DNS provider: both that they are trustworthy and that they have their server secured properly. You also have to trust any recursive DNS lookups your provider does and each of their intentions and configurations.
DNSSEC, on the other hand, signs the records that you're returned (like PGP signed emails) but it doesn't encrypt the traffic. Someone could still snoop on your DNS traffic and see what you're looking up, but with the hierarchical set of signed records no-one except the authoritative name server can change the answer. Not your DNS provider nor any other resolvers they depend on.
It's the difference between getting your email over IMAPS and having it PGP signed -- you don't need to trust every intermediary. Yet I don't see anyone saying, "since we can now to SMTP and IMAP over SSL we don't need PGP or SMIME."
You could certainly use both: DNSCurve to provide encryption, so that no-one but your DNS provider knows what you're looking up, and DNSSEC so you know it is actually a valid record.