There are self-encrypting tape drives and hard disks that satisfy FIPS 140-2: adequate for "sensitive but unclassified data". If you have very high value data and are facing an APT style of adversary, your concerns would be valid. For "buy random hard disk and harvest blackmail and ID theft fodder", standard compliant crypto will be quite sufficient to make the attacker move on to easier pickings.
Sorry, but I disagree. I work for an academic employer (a supercomputing centre), and the environment that now exists in that workplace is much as Dracolytch spelled out in his second post. We really want to work alongside people who are prepared to think about more than the immediate next step in getting a problem to go away. I'm not a manager, and barring something drastic happening, I will not be in the foreseeable future, but I really value being able to work alongside people who, y'know, care about getting to the root of problems and fixing them in ways that help improve the lot of other staff and our user base. As for whether this is really "passionate", I'd prefer to say something like "thoughtful, considerate, productive and interested in learning."
But I strongly dispute that, in the sense Dracolytch seems to be using it, it means "enthusiastic to the point of being exploitable". We *did* see that sort of boundary violation in our organisation with one manager who was thankfully moved sideways to other responsibilities: key people were being poached from other teams and grossly overcommitted to an endless series of new projects, expected to take on way-out-of-hours problems on office hours pay, with absolutely no formal overtime or on-call provisions (how wonderful it was to receive a text from that manager at 12:30am offering me the root passwords to a storage service the manager wanted to see brought back online when the main admins were on leave, having previously been actively ignored and excluded from that part of the business by the same manager), and generally jerked around like marionettes in a hurricane as the manager pursued his strange agendas of trying to take on any data storage job that would bring in some bucks without any detailed capacity planning or workload modelling. People had to learn on the fly to get things running ASAP; testing was minimal, mistakes were made, and the resulting services were slow and unreliable. It was a very demoralizing time, and everyone was glad to finally see a manager appointed for operations who started planning, listening to his staff and concentrating on delivering a core set of reliable, well-managed services. Even so, everyone still needs to bring a decent level of enthusiasm for fixing problems, building well-engineered systems, looking at the bigger picture, and learning new things. Petaflop-scale HPC and storage is not a turnkey operation, and it's not advisable to kick back and coast along if you are planning to be around when the chickens come home to roost.
"Following the fashion of HPC" is a bit harsh. It depends on whether the research group gets money (which they could spend on exactly the sort of compute that would suit them) or in-kind funding with grants of time at an existing large HPC site, and how much data they expect to produce, and where/how long they intend to store it. For instance, Australian university researchers had to pay ISP traffic charges on top of Amazon's own charges to download data from Amazon until November of 2012, when AARNET peered with Amazon, and then only for data downloaded from the US-WEST-2 region.
Also, if the research group is small, it depends a lot on who handles their IT support. If (because of the in-kind funding) they are depending on the expertise of the HPC site for support, then a lot is down to the particular HPC site and whether it has as much depth in supporting cloud workloads as traditional HPC workloads.
...will find this the sort of thing they like. For people/groups who have SETI@home or Folding@home style workloads - the type that the HPC community call "embarrassingly parallel" - and some money, this is useful. But it's sad that there is no mention made in the article of Condor - a job manager for loosely coupled machines that has been doing the same kind of thing since the '80s - essentially, since there has been a network between a few sometimes-idle computers in a CS department. Cycle Computing itself has used Condor as part of its CycleServer product. Jupiter is their own task distribution system which goes to larger scales than Condor can reach.
It's cool that Cycle Computing have packaged up this cycle scavenging approach into infrastructure that lets people easily deploy and farm work out to EC2 spot instances. But as they make those instances easier to use, the demand will go up, and the spot price of compute capacity will likely go up too. Which is nice for Amazon, of course, but harder on groups that are trying to make a budget forecast of what their simulations will cost to run. The free market grid computing cheerleader types will be over the moon at the opportunity to write papers about spot instance futures markets on a service that actually got popular. But, as another poster points out, it's High Throughput Computing, not HPC, and the very thing that makes it amenable to spot markets, which is the fungibility of loosely coupled EC2 instances, also restricts it to loosely coupled workloads, especially ones that don't produce a huge amount of data for each separate run - although a couple of years ago Cycle were already looking at ways of improving this last restriction.
My 3D printer uses about 20 watts. So the power costs about a penny per day.
Does that power come from a power grid, or from solar? Who makes the semiconductors for the solar panels, and the chips in the printer? How much did they cost and how did you pay for them? How long does it take you to make an item like, say, a bucket?
maintain it
The robots should be able to repair and maintain each other. If not, then that is job for someone!
If the robots aren't up to repairing each other, and unless that someone is me, I will need to pay them. What should I pay them with - 3D printed goods that they can make themselves?
and keep it fed with the necessary materials
Current replicators use extruded plastic, but people are already working on making them work with shredded recycled plastic, and recycled powdered metal. So if you run out of raw materials, just go gather up some bottles or cans from the side of the road.
Just as the world's bio-diesel needs can not be met from recycled takeaway fryer oil, the "pick up other people's discarded stuff to feed my 3D printer" model is just as unscalable. Scattered, cottage industry is not the same as keeping the world running using only waste stuff.
Look, I think that 3D printing is nifty, and recycling stuff is awesome, and using things that people don't want is great - I'm one of those people that hardly ever buys anything technological until it goes on closeout sale - but it's a big stretch to claim that owning a magic printing machine and an R2-D2 to fix it will allow people to survive in a future where their labour has little selling proposition, let alone a unique selling proposition. What I want to understand is how owning some robot buddies lets you either live decently while sitting completely apart from the post-singularity economy, or participate meaningfully in it, when everything that you can do could be done by anyone else with the same gadgets.
So if I have a machine that will produce anything I want, at the push of a button, I will be poor and have to beg. I am not sure I follow your logic.
If you have that machine, and the means to power, maintain, and keep it fed with the necessary materials, you'll be doing super fine. A few assumptions there.
Until AIs get the right to enter into contracts and own property, there will always be a role for a small number of humans to own all the stuff. They will of course be first to get access to anti-aging and life extension technologies, and Andrew Carnegie's idea that "the man who dies rich dies disgraced" will be less of an incentive to philanthropy once that moment of disgrace is pushed back into the indefinite future.
Just as computers do most repetitive, regular information work now, robots are going to do more and more manual work which can easily be systematized. What will be left will be ad hoc, messy, fiddly stuff, or face-to-face contact. In other words, there will always be plenty of crappy jobs in the service industries.
"If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?" - Seymour Cray.
The devil is in the details. SPARC has lots of registers, very true. But it needs more user-accessible registers, because its address modes are simpler, and you need to do more address computations in registers. Register windows were like a fully associative cache for a few levels of your call stack... but then you have to save more stuff when you do a context switch, and I suspect they were part of why Sun was late to doing full out-of-order execution in their SPARC implementations.
I was a big fan of the early RISC chips, because that architectural style was bringing forth implementations which got much better bang per CPU transistor than other commercial chips at the time. That lead was eroded seriously by Intel with the Pentium Pro - certainly in terms of bang per buck - which was embarrassing for people who wanted to point out some inherent "elegance" or other timeless quality of RISC that was its great advantage. Whatever that counted for, Intel's designs and better process technology could more or less match with ugly old x86.
The time when you could play Top Trumps with computer architecture specs is really over. Decisions that were clear winners at a particular time, in terms of process technology, memory bandwidths, and compiler quality, can turn out not to be as optimal when the market, or what is cost-effective to produce, changes over time.
The T series SPARC chips came out of work done by Kunle Olukotun at Afara Websystems and then brought in-house by Sun. They represented a great point-in-time improvement for high parallelism, cache-unfriendly, integer server loads over what was under development inside Sun at the same time, especially when cost and power were taken into account. Some of those decisions in the T1 got revised for the T2 - one FPU for the whole chip turned into one FPU per core, for instance - but the per-die core count got halved for the T4, so again the Top Trumps viewpoint doesn't really illustrate whether one processor is better than another.
Bottom line is, does it run the stuff you want to run, for a good TCO?
Yeah, do not buy old Sun hardware thinking that you can get any useful support from third parties, or pick up a cheap support contract suitable for a sysadmin's home box or a dev workstation... or even download firmware for a device that is not covered by your current support contract. That sort of thing went away by or shortly after the time that Oracle bought Sun.
Oracle doesn't really care about ISV support for SPARC, and they probably like it if their big Oracle/SPARC sales included a hefty dose of high margin professional services to cover the customer's inexperience with the hardware platform, so why do they need ordinary people using SPARC anyway?
"You actually don't need to be open-minded about Oracle. You are wasting the openness of your mind..." - Bryan Cantrill, Fork Yeah!
One of the "RISC sucks, it'll never take off" complaints was "if I wanted to write microcode I would have gotten onto the VAX design team".
The funny thing being that the complainer apparently wanted to spend their life writing assembly code.:-)
It's like big-endian versus little-endian memory organisation: on the one hand, you have a data format that makes it a bit easier to read raw hex dumps of main memory, but does your head in whenever you want actually write something useful (like, picking out the nth significant byte from a multibyte data type), while little-endian looks ugly on paper, but makes writing code to do multiple precision stuff simpler - the bit with significance 2^n is in the byte at [baseaddr + (n>>3)], no matter *what* length the full data type is... and the debugger will helpfully display that ugly little-endian piece of memory properly for you should you need to see it.
John Mashey, one of the MIPS architecture designers among many other things, has written a really good essay on RISC architectural choices.
He posted it to the comp.arch USENET group a few times; here's a copy of that post that renders in a monospace font so you can read the ASCII tables easily. [Google Groups' version makes the tables unreadable.]
The best rule of thumb I like to remember from that essay is that RISC architectures try to make exception handling simple; for example, they don't tend to use the MMU for data access more than once per instruction, because then you have multiple ways that the instruction can generate an exception. Other RISC choices can be seen as stemming from this rule, such as: - no variable-length string comparison/move instructions - accesses to multibyte data are aligned so they can't cross page boundaries - load/store architectures; this keeps MMU exceptions and ALU exceptions from ever being generated by the same instruction.
The more complex the exception handling requirements, the more you pay to implement those, either with more hardware, [which can imply more cost, or more power, or longer cycle time], or by giving up opportunities for parallelism because the exceptions get too hard to handle with many operations in flight. Even if an exception is rare compared to the common case, the implementation has to be able to handle it correctly...
Hell, I wrote exactly what people are talking about here in an afternoon in college - I even did both SHA and MD5, because I ended up finding a SHA collision between one of the Quake 3 files and a Linux system file.
It would be interesting to know how long each of these colliding files was... funny how we all *know* that for nontrivial hash inputs there are many many possible colliding inputs, but over time we tend to slide into "let's just compare hashes to find identical data; collisions are so rare - after all, we haven't seen any!"
Part of BMW's response FTFA: "A vital point to acknowledge here is that there is no such thing as the ‘unstealable’ car, as Ron Cliff knows well. If a criminal decides they want your car, they will find a way to take it. Our job is to make it as difficult as possible."
Apparently, that means making it take three minutes, instead of, say, two and a half. Dare we dream one day of the car that can resist theft for... four minutes?
Anyone who thinks that tinnitus adds anything to life is kidding themselves. Constant ringing in your ears, worse with stress or fatigue.
I have much accumulated damage to my body, but my highest priority for improvement would be my hearing. I don't mind wearing a splint for the rest of my life to save my teeth from finally wearing to the point of mechanical failure, but I hate having tinnitus and high frequency hearing loss.
Look after your diet, people - your small blood vessels in your middle ear can get constricted with fatty crap just like your big arteries around your heart can. Reduced blood supply => increased oxidative stress => less robust neurons in your ears => increased risk of hearing loss after noise exposure.
...holding patents on: - FM Synthesis (John Chowning at CCRMA) - PageRank (a certain Larry Page and Sergei Brin)
Yamaha licensed the FM synthesis patents, and later waveguide synthesis patents, that stemmed from work at CCRMA, part of Stanford. Google holds an exclusive license to the PageRank patent.
Stanford certainly doesn't sell musical instruments or search engine services, so does that make them patent trolls? Maybe Stanford hasn't ever had to sue any other companies to enforce their rights on these patents, but that could simply be down to people knowing not to mess with an institution backed by that kind of intellectual and financial firepower. Having made considerable profit from these patents, do you think it likely that Stanford would lie down and let some company use these patents without licensing them?
"I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours." -Stephen Roberts
Thanks very much for this quote! I have been saying basically the same thing, albeit less eloquently, for years, but never came across this quote.
Maybe advanced magic prevents MPEG-4 compression artifacts from being just as annoying as MPEG-2 compression artifacts, but it would seem shortsighted to devalue what is supposed to be the premium movie viewing experience (digital projectors, in a cinema) by using consumer grade compression. I see enough melty faces on standard definition DVB-T broadcasts that I remain skeptical about the invisibility of MPEG-4 compression, especially when the result is blown up to huge proportions and the film has lots of special effects. I am not going to a cinema to look at blocky crap where the compression algorithm ran out of bits for the breaking waves or rushing water or full-on special effects.
Anyway, all of that P- and B-frame stuff is just to get the bit rate down to the point where a movie fits on a nice, cheap-to-produce piece of optical media sold to individual households. The economic equation is totally different for the media that is used to exhibit a film to (hopefully!) many people, and it's not like making a physical print and shipping it around was very cheap either.
Flicker depends a lot on the shutter angle (proportion of frame time that the film is exposed for) as well, for traditional film cameras.
Small shutter angle => short exposure => more flicker on fast action. Think "Saving Private Ryan" beach landing scene - little bits of dirt from explosions caught in mid-air for a single frame by the short per-frame exposure. A flow-on is that such shots often have more grain and less colour saturation, because the film needs to be of a faster type to get properly exposed at these shorter exposure times using practical amounts of light -- especially for outdoor scenes.
"Bully" should only be used as a verb - "bullying". The noun should instead be "vicious shithead". People who enjoy inflicting pain on people should not be called bullies, but vicious shitheads.
It is of course possible to stop being a vicious shithead. I was one too - I bullied my brother, because I was so angry at the breakdown of my parents' marriage and being bullied myself; I was an Asperger's space cadet bully magnet. I bullied another pupil at my school, until the day he fought back and I realised that right then there was nothing separating me from the shitheads who called me a faggot so often I ended up questioning my own sexuality by the end of high school and were always threatening me with violence... sometimes more than just threats. I never bullied again after that day.
Later I apologised to my brother. I should have apologised to that pupil too, but I was too much of a coward then. What I have learned since that day, in adult life, is that almost nobody wants to admit that their shit stinks as much as anyone else's, let alone that their actions and attitudes are especially toxic and fucked. Doesn't change the fact that if someone enjoys inflicting pain on someone else (who doesn't consent, please insert obligatory "BDSM is a valid lifestyle" whalesong here) they aren't a mere "bully", they are a vicious shithead.
As for the premature aging signs that are mentioned in the original post - I can believe it. Due to some stupid life choices, I ended up living on a farm with my alpha male father-in-law, who felt no great restraint against venting his toxic temper whenever things didn't go his way - and I ended up with crippling osteoarthritic pain in my knees and wrists so bad that I could not walk up stairs without bracing my knees with my hands. Thankfully I eventually managed these symptoms with concentrated fish oil extracts and glucosamine, both of which have been reported to moderate inflammation responses. But I am under no illusion that my body is in anything other than "fuck off and die young" mode because of the social situation that I find myself in. My continued ability to do the manual work this lifestyle requires is as far as I can tell dependent on my luck in finding some appropriate dietary supplements. Before I started taking those, I could hardly get out of my car to open the farm gates on my daily commute. Chronic oxidative stress fucks you up good and proper.
When I was at home during the day over the Christmas holiday period, a number of the "hello, this is the technical support centre, your Microsoft Windows computer has a virus [so please install our trojan software to remove the bogus virus, you chump]" scam callers had an accent that sounded Filipino to me, and spoke pretty clearly compared to the Indian accented callers I had heard before. Perhaps I was experiencing the benefits of US-funded English training in the Phillipines.
NB: This is not any racist remark, just my experience of a number of phone calls (1 or 2 per day) that I received when I happened to be home for a week. It got to the point where I was interrupting them with "Oh, you're calling about the computer, aren't you?" within a second of them starting their patter. It was a small consolation to hear the pause and uncertain "..yes?" before I hung up on them.
When the labour of humans with Internet access is so plentiful and cheap, you can try all the same "works one in a hundred times" scams that used only to be economical to automate, but now your scam mechanism can talk, interpret speech, pass a Turing test and solve CAPTCHAs...
I can hear a Zippy quote: "SINGAPORE has instituted PERMANENT PUNCTUALITY!" How fitting.
But seriously, I can't think of any justification for Daylight Savings near the equator. Where I live in Australia, which is only 35 degrees south, it used to get pretty annoying waking up at 5:00 in the morning with the sun in spring, because DST used to start at the end of October. Now that DST starts at the beginning of October, sunrise only gets to about 05:40 before DST kicks in.
The boards are in manufacturing, expected to complete on Feb 20th. The most recent holdup came down to a misunderstanding as to whether a particular form factor of piezo crystal was easily available in China at the expected price, because the same crystal is easily available and cheap in the UK. The Raspberry Pi team have been incredibly open and patient in explaining to the many, many people visiting their web site how the design decisions have been made, and what has been taking all the time in going from an alpha board prototype to a ready to manufacture product.
When the goal is to produce something in large quantities for low price, and the project is done by people with great skill but also other competing demands on their time (like, their day jobs), it's not surprising there have been some delays in trying to get the board design to the point of manufacture. I've been following the project for months, and it has struck me how the degree of openness of this project has added more work for the RasPi team in having to clarify/dispel misconceptions and ill-founded rumours - such as when a simple mention of 10,000 "parts kits" being on order caused some people to start thinking that the RasPi was not going to be fully assembled, simply because they didn't understand the meaning of that phrase in that context, and had not read the FAQ - and yet the RasPi team keep telling us what is going on because that is the ethos of the project.
I've got no association with the project, other than frank admiration at their dedication and focus on meeting their real goals, which is not to ship device X by time T, but to spark a renewed interest in the actual study and practise of computing.
Parent post hits nail squarely on head. Just because Random Hopeless CA X is still in a browser's trusted root CA list, should not mean that they can issue certs against my domain that anyone should trust. Placing signed cert public key fingerprints (or even the public key fingerprint of the root CA that actually issues your cert, if you really trust that CA) would make it much harder for an attacker to compromise a well-run, high-value web site (such as gmail.com or a banking web site).
Google did this unilaterally in their own browser, by only trusting the small set of CAs that Google uses when accessing its own web sites. Neat, but not at all scalable, even if Google were motivated to extend that feature to high-value web sites run by other companies.
Grid computing had a similar idea - if you wanted to get your CA's certificate into the bundle of trusted CAs distributed with common Grid software bundles like Globus or VDT, your CA had to have a "signing authority" that limited what certificate subjects it could sign for, which was part of the CA certificate. This meant that even if I compromised Random Trusted Grid CA X, I could not issue a cert that claimed I was from, say, Fermilab, because that cert would not match against the signing authority for that other Grid CA. Commercial CAs would never agree to similar provisions, because that would restrict who they could sell certs to, but the parent post's idea devolves that signing authority down to the people who actually pay for the certificate, which is naturally where that authority should reside.
Best of all, to implement this scheme, you just need to create an appropriate DNS record, add the check to your preferred open source web browser, and start selling the idea to the browser users and web site operators. With luck, the public support for the idea gets it adopted by web site operators (it costs them almost nothing), CAs have nothing to object to because they can still sell certs to whoever they were already selling certs to, and browser users put pressure on the developers to support the scheme. You don't have to persuade everyone to swallow a barrel of crypto-anarchist-libertarian "decentralise everything, storm the Winter Palace, power to the people, right on!" Kool-Aid and destroy the existing PKI CA architecture in order to save it.
The creation of the universe is something wholly outside of all human experience, and no person who was ever born has ever had any personal knowledge or experience of anything coming out of nothing, so it's not really unreasonable for anyone to conclude that a nebula is actually many billions of years old based on that experience... But rational or not, such a conclusion based solely on that experience is really nothing more than rationalized self-deception.
It is also true that no person who was ever born has ever had any personal knowledge or experience of any impossible state of affairs. That does not make any impossible thing more possible just because we don't know what it would be like to experience that impossible thing. Or, indeed, help us work out which impossible thing would be more likely.
How about you work out a consensus "God(s) made everything we see just like so" story with all the other religions than the one you happen to cleave to? Because, by the same token you would not necessarily know how to recognise the world as a creation of Brahma, Eurynome and Ophion, Mazda, or the Flying Spaghetti Monster, rather than your god. Who knows, you might end up looking at the world to find evidence of a specific creation story. How would you weigh one religion's claim for justification based on one piece of evidence with other evidence that supports your preferred religion? Or different interpretations of the same evidence? You might need to develop some theories of natural science that let you tell the commonplace from the extraordinary. You will no doubt be relieved to find that there happen to be some quite useful theories of that sort knocking around already, that have been refined for many centuries. Feel free to use them to rationalise however much self-deception you need in order to elevate your creation story over all the others.
[...] He is not allowed to sit there and do nothing but watch TV. My wife plays and draws and bakes cookies and everything else you would expect a young child do.
I expected a lot from my young children, but I never expected them to bake cookies!
(My wife plays and draws and bakes cookies with my kids too, BTW... sorry, I just couldn't resist the exploitable typo:-)
Slashdot Mirror
There are self-encrypting tape drives and hard disks that satisfy FIPS 140-2: adequate for "sensitive but unclassified data".
If you have very high value data and are facing an APT style of adversary, your concerns would be valid. For "buy random hard disk and harvest blackmail and ID theft fodder", standard compliant crypto will be quite sufficient to make the attacker move on to easier pickings.
Sorry, but I disagree. I work for an academic employer (a supercomputing centre), and the environment that now exists in that workplace is much as Dracolytch spelled out in his second post. We really want to work alongside people who are prepared to think about more than the immediate next step in getting a problem to go away. I'm not a manager, and barring something drastic happening, I will not be in the foreseeable future, but I really value being able to work alongside people who, y'know, care about getting to the root of problems and fixing them in ways that help improve the lot of other staff and our user base. As for whether this is really "passionate", I'd prefer to say something like "thoughtful, considerate, productive and interested in learning."
But I strongly dispute that, in the sense Dracolytch seems to be using it, it means "enthusiastic to the point of being exploitable". We *did* see that sort of boundary violation in our organisation with one manager who was thankfully moved sideways to other responsibilities: key people were being poached from other teams and grossly overcommitted to an endless series of new projects, expected to take on way-out-of-hours problems on office hours pay, with absolutely no formal overtime or on-call provisions (how wonderful it was to receive a text from that manager at 12:30am offering me the root passwords to a storage service the manager wanted to see brought back online when the main admins were on leave, having previously been actively ignored and excluded from that part of the business by the same manager), and generally jerked around like marionettes in a hurricane as the manager pursued his strange agendas of trying to take on any data storage job that would bring in some bucks without any detailed capacity planning or workload modelling. People had to learn on the fly to get things running ASAP; testing was minimal, mistakes were made, and the resulting services were slow and unreliable. It was a very demoralizing time, and everyone was glad to finally see a manager appointed for operations who started planning, listening to his staff and concentrating on delivering a core set of reliable, well-managed services. Even so, everyone still needs to bring a decent level of enthusiasm for fixing problems, building well-engineered systems, looking at the bigger picture, and learning new things. Petaflop-scale HPC and storage is not a turnkey operation, and it's not advisable to kick back and coast along if you are planning to be around when the chickens come home to roost.
"Following the fashion of HPC" is a bit harsh. It depends on whether the research group gets money (which they could spend on exactly the sort of compute that would suit them) or in-kind funding with grants of time at an existing large HPC site, and how much data they expect to produce, and where/how long they intend to store it. For instance, Australian university researchers had to pay ISP traffic charges on top of Amazon's own charges to download data from Amazon until November of 2012, when AARNET peered with Amazon, and then only for data downloaded from the US-WEST-2 region.
Also, if the research group is small, it depends a lot on who handles their IT support. If (because of the in-kind funding) they are depending on the expertise of the HPC site for support, then a lot is down to the particular HPC site and whether it has as much depth in supporting cloud workloads as traditional HPC workloads.
...will find this the sort of thing they like. For people/groups who have SETI@home or Folding@home style workloads - the type that the HPC community call "embarrassingly parallel" - and some money, this is useful. But it's sad that there is no mention made in the article of Condor - a job manager for loosely coupled machines that has been doing the same kind of thing since the '80s - essentially, since there has been a network between a few sometimes-idle computers in a CS department. Cycle Computing itself has used Condor as part of its CycleServer product. Jupiter is their own task distribution system which goes to larger scales than Condor can reach.
It's cool that Cycle Computing have packaged up this cycle scavenging approach into infrastructure that lets people easily deploy and farm work out to EC2 spot instances. But as they make those instances easier to use, the demand will go up, and the spot price of compute capacity will likely go up too. Which is nice for Amazon, of course, but harder on groups that are trying to make a budget forecast of what their simulations will cost to run. The free market grid computing cheerleader types will be over the moon at the opportunity to write papers about spot instance futures markets on a service that actually got popular. But, as another poster points out, it's High Throughput Computing, not HPC, and the very thing that makes it amenable to spot markets, which is the fungibility of loosely coupled EC2 instances, also restricts it to loosely coupled workloads, especially ones that don't produce a huge amount of data for each separate run - although a couple of years ago Cycle were already looking at ways of improving this last restriction.
If you have that machine, and the means to power
My 3D printer uses about 20 watts. So the power costs about a penny per day.
Does that power come from a power grid, or from solar? Who makes the semiconductors for the solar panels, and the chips in the printer? How much did they cost and how did you pay for them? How long does it take you to make an item like, say, a bucket?
maintain it
The robots should be able to repair and maintain each other. If not, then that is job for someone!
If the robots aren't up to repairing each other, and unless that someone is me, I will need to pay them. What should I pay them with - 3D printed goods that they can make themselves?
and keep it fed with the necessary materials
Current replicators use extruded plastic, but people are already working on making them work with shredded recycled plastic, and recycled powdered metal. So if you run out of raw materials, just go gather up some bottles or cans from the side of the road.
Just as the world's bio-diesel needs can not be met from recycled takeaway fryer oil, the "pick up other people's discarded stuff to feed my 3D printer" model is just as unscalable. Scattered, cottage industry is not the same as keeping the world running using only waste stuff.
Look, I think that 3D printing is nifty, and recycling stuff is awesome, and using things that people don't want is great - I'm one of those people that hardly ever buys anything technological until it goes on closeout sale - but it's a big stretch to claim that owning a magic printing machine and an R2-D2 to fix it will allow people to survive in a future where their labour has little selling proposition, let alone a unique selling proposition. What I want to understand is how owning some robot buddies lets you either live decently while sitting completely apart from the post-singularity economy, or participate meaningfully in it, when everything that you can do could be done by anyone else with the same gadgets.
So if I have a machine that will produce anything I want, at the push of a button, I will be poor and have to beg. I am not sure I follow your logic.
If you have that machine, and the means to power, maintain, and keep it fed with the necessary materials, you'll be doing super fine. A few assumptions there.
Until AIs get the right to enter into contracts and own property, there will always be a role for a small number of humans to own all the stuff. They will of course be first to get access to anti-aging and life extension technologies, and Andrew Carnegie's idea that "the man who dies rich dies disgraced" will be less of an incentive to philanthropy once that moment of disgrace is pushed back into the indefinite future.
Just as computers do most repetitive, regular information work now, robots are going to do more and more manual work which can easily be systematized. What will be left will be ad hoc, messy, fiddly stuff, or face-to-face contact. In other words, there will always be plenty of crappy jobs in the service industries.
"If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?" - Seymour Cray.
The devil is in the details. SPARC has lots of registers, very true. But it needs more user-accessible registers, because its address modes are simpler, and you need to do more address computations in registers. Register windows were like a fully associative cache for a few levels of your call stack... but then you have to save more stuff when you do a context switch, and I suspect they were part of why Sun was late to doing full out-of-order execution in their SPARC implementations.
I was a big fan of the early RISC chips, because that architectural style was bringing forth implementations which got much better bang per CPU transistor than other commercial chips at the time. That lead was eroded seriously by Intel with the Pentium Pro - certainly in terms of bang per buck - which was embarrassing for people who wanted to point out some inherent "elegance" or other timeless quality of RISC that was its great advantage. Whatever that counted for, Intel's designs and better process technology could more or less match with ugly old x86.
The time when you could play Top Trumps with computer architecture specs is really over. Decisions that were clear winners at a particular time, in terms of process technology, memory bandwidths, and compiler quality, can turn out not to be as optimal when the market, or what is cost-effective to produce, changes over time.
The T series SPARC chips came out of work done by Kunle Olukotun at Afara Websystems and then brought in-house by Sun. They represented a great point-in-time improvement for high parallelism, cache-unfriendly, integer server loads over what was under development inside Sun at the same time, especially when cost and power were taken into account. Some of those decisions in the T1 got revised for the T2 - one FPU for the whole chip turned into one FPU per core, for instance - but the per-die core count got halved for the T4, so again the Top Trumps viewpoint doesn't really illustrate whether one processor is better than another.
Bottom line is, does it run the stuff you want to run, for a good TCO?
Yeah, do not buy old Sun hardware thinking that you can get any useful support from third parties, or pick up a cheap support contract suitable for a sysadmin's home box or a dev workstation... or even download firmware for a device that is not covered by your current support contract. That sort of thing went away by or shortly after the time that Oracle bought Sun.
Oracle doesn't really care about ISV support for SPARC, and they probably like it if their big Oracle/SPARC sales included a hefty dose of high margin professional services to cover the customer's inexperience with the hardware platform, so why do they need ordinary people using SPARC anyway?
"You actually don't need to be open-minded about Oracle. You are wasting the openness of your mind..." - Bryan Cantrill, Fork Yeah!
One of the "RISC sucks, it'll never take off" complaints was "if I wanted to write microcode I would have gotten onto the VAX design team".
The funny thing being that the complainer apparently wanted to spend their life writing assembly code. :-)
It's like big-endian versus little-endian memory organisation: on the one hand, you have a data format that makes it a bit easier to read raw hex dumps of main memory, but does your head in whenever you want actually write something useful (like, picking out the nth significant byte from a multibyte data type), while little-endian looks ugly on paper, but makes writing code to do multiple precision stuff simpler - the bit with significance 2^n is in the byte at [baseaddr + (n>>3)], no matter *what* length the full data type is... and the debugger will helpfully display that ugly little-endian piece of memory properly for you should you need to see it.
John Mashey, one of the MIPS architecture designers among many other things, has written a really good essay on RISC architectural choices.
He posted it to the comp.arch USENET group a few times; here's a copy of that post that renders in a monospace font so you can read the ASCII tables easily. [Google Groups' version makes the tables unreadable.]
The best rule of thumb I like to remember from that essay is that RISC architectures try to make exception handling simple; for example, they don't tend to use the MMU for data access more than once per instruction, because then you have multiple ways that the instruction can generate an exception. Other RISC choices can be seen as stemming from this rule, such as:
- no variable-length string comparison/move instructions
- accesses to multibyte data are aligned so they can't cross page boundaries
- load/store architectures; this keeps MMU exceptions and ALU exceptions from ever being generated by the same instruction.
The more complex the exception handling requirements, the more you pay to implement those, either with more hardware, [which can imply more cost, or more power, or longer cycle time], or by giving up opportunities for parallelism because the exceptions get too hard to handle with many operations in flight. Even if an exception is rare compared to the common case, the implementation has to be able to handle it correctly...
Hell, I wrote exactly what people are talking about here in an afternoon in college - I even did both SHA and MD5, because I ended up finding a SHA collision between one of the Quake 3 files and a Linux system file.
It would be interesting to know how long each of these colliding files was... funny how we all *know* that for nontrivial hash inputs there are many many possible colliding inputs, but over time we tend to slide into "let's just compare hashes to find identical data; collisions are so rare - after all, we haven't seen any!"
Part of BMW's response FTFA:
"A vital point to acknowledge here is that there is no such thing as the ‘unstealable’ car, as Ron Cliff knows well. If a criminal decides they want your car, they will find a way to take it. Our job is to make it as difficult as possible."
Apparently, that means making it take three minutes, instead of, say, two and a half. Dare we dream one day of the car that can resist theft for... four minutes?
Anyone who thinks that tinnitus adds anything to life is kidding themselves. Constant ringing in your ears, worse with stress or fatigue.
I have much accumulated damage to my body, but my highest priority for improvement would be my hearing. I don't mind wearing a splint for the rest of my life to save my teeth from finally wearing to the point of mechanical failure, but I hate having tinnitus and high frequency hearing loss.
Look after your diet, people - your small blood vessels in your middle ear can get constricted with fatty crap just like your big arteries around your heart can. Reduced blood supply => increased oxidative stress => less robust neurons in your ears => increased risk of hearing loss after noise exposure.
...holding patents on:
- FM Synthesis (John Chowning at CCRMA)
- PageRank (a certain Larry Page and Sergei Brin)
Yamaha licensed the FM synthesis patents, and later waveguide synthesis patents, that stemmed from work at CCRMA, part of Stanford.
Google holds an exclusive license to the PageRank patent.
Stanford certainly doesn't sell musical instruments or search engine services, so does that make them patent trolls? Maybe Stanford hasn't ever had to sue any other companies to enforce their rights on these patents, but that could simply be down to people knowing not to mess with an institution backed by that kind of intellectual and financial firepower. Having made considerable profit from these patents, do you think it likely that Stanford would lie down and let some company use these patents without licensing them?
"I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours." -Stephen Roberts
Thanks very much for this quote! I have been saying basically the same thing, albeit less eloquently, for years, but never came across this quote.
Maybe advanced magic prevents MPEG-4 compression artifacts from being just as annoying as MPEG-2 compression artifacts, but it would seem shortsighted to devalue what is supposed to be the premium movie viewing experience (digital projectors, in a cinema) by using consumer grade compression. I see enough melty faces on standard definition DVB-T broadcasts that I remain skeptical about the invisibility of MPEG-4 compression, especially when the result is blown up to huge proportions and the film has lots of special effects. I am not going to a cinema to look at blocky crap where the compression algorithm ran out of bits for the breaking waves or rushing water or full-on special effects.
Anyway, all of that P- and B-frame stuff is just to get the bit rate down to the point where a movie fits on a nice, cheap-to-produce piece of optical media sold to individual households. The economic equation is totally different for the media that is used to exhibit a film to (hopefully!) many people, and it's not like making a physical print and shipping it around was very cheap either.
Flicker depends a lot on the shutter angle (proportion of frame time that the film is exposed for) as well, for traditional film cameras.
Small shutter angle => short exposure => more flicker on fast action. Think "Saving Private Ryan" beach landing scene - little bits of dirt from explosions caught in mid-air for a single frame by the short per-frame exposure. A flow-on is that such shots often have more grain and less colour saturation, because the film needs to be of a faster type to get properly exposed at these shorter exposure times using practical amounts of light -- especially for outdoor scenes.
"Bully" should only be used as a verb - "bullying". The noun should instead be "vicious shithead". People who enjoy inflicting pain on people should not be called bullies, but vicious shitheads.
It is of course possible to stop being a vicious shithead. I was one too - I bullied my brother, because I was so angry at the breakdown of my parents' marriage and being bullied myself; I was an Asperger's space cadet bully magnet. I bullied another pupil at my school, until the day he fought back and I realised that right then there was nothing separating me from the shitheads who called me a faggot so often I ended up questioning my own sexuality by the end of high school and were always threatening me with violence... sometimes more than just threats. I never bullied again after that day.
Later I apologised to my brother. I should have apologised to that pupil too, but I was too much of a coward then. What I have learned since that day, in adult life, is that almost nobody wants to admit that their shit stinks as much as anyone else's, let alone that their actions and attitudes are especially toxic and fucked. Doesn't change the fact that if someone enjoys inflicting pain on someone else (who doesn't consent, please insert obligatory "BDSM is a valid lifestyle" whalesong here) they aren't a mere "bully", they are a vicious shithead.
As for the premature aging signs that are mentioned in the original post - I can believe it. Due to some stupid life choices, I ended up living on a farm with my alpha male father-in-law, who felt no great restraint against venting his toxic temper whenever things didn't go his way - and I ended up with crippling osteoarthritic pain in my knees and wrists so bad that I could not walk up stairs without bracing my knees with my hands. Thankfully I eventually managed these symptoms with concentrated fish oil extracts and glucosamine, both of which have been reported to moderate inflammation responses. But I am under no illusion that my body is in anything other than "fuck off and die young" mode because of the social situation that I find myself in. My continued ability to do the manual work this lifestyle requires is as far as I can tell dependent on my luck in finding some appropriate dietary supplements. Before I started taking those, I could hardly get out of my car to open the farm gates on my daily commute. Chronic oxidative stress fucks you up good and proper.
When I was at home during the day over the Christmas holiday period, a number of the "hello, this is the technical support centre, your Microsoft Windows computer has a virus [so please install our trojan software to remove the bogus virus, you chump]" scam callers had an accent that sounded Filipino to me, and spoke pretty clearly compared to the Indian accented callers I had heard before. Perhaps I was experiencing the benefits of US-funded English training in the Phillipines.
NB: This is not any racist remark, just my experience of a number of phone calls (1 or 2 per day) that I received when I happened to be home for a week. It got to the point where I was interrupting them with "Oh, you're calling about the computer, aren't you?" within a second of them starting their patter. It was a small consolation to hear the pause and uncertain "..yes?" before I hung up on them.
When the labour of humans with Internet access is so plentiful and cheap, you can try all the same "works one in a hundred times" scams that used only to be economical to automate, but now your scam mechanism can talk, interpret speech, pass a Turing test and solve CAPTCHAs...
I can hear a Zippy quote: "SINGAPORE has instituted PERMANENT PUNCTUALITY!" How fitting.
But seriously, I can't think of any justification for Daylight Savings near the equator. Where I live in Australia, which is only 35 degrees south, it used to get pretty annoying waking up at 5:00 in the morning with the sun in spring, because DST used to start at the end of October. Now that DST starts at the beginning of October, sunrise only gets to about 05:40 before DST kicks in.
The boards are in manufacturing, expected to complete on Feb 20th. The most recent holdup came down to a misunderstanding as to whether a particular form factor of piezo crystal was easily available in China at the expected price, because the same crystal is easily available and cheap in the UK. The Raspberry Pi team have been incredibly open and patient in explaining to the many, many people visiting their web site how the design decisions have been made, and what has been taking all the time in going from an alpha board prototype to a ready to manufacture product.
When the goal is to produce something in large quantities for low price, and the project is done by people with great skill but also other competing demands on their time (like, their day jobs), it's not surprising there have been some delays in trying to get the board design to the point of manufacture. I've been following the project for months, and it has struck me how the degree of openness of this project has added more work for the RasPi team in having to clarify/dispel misconceptions and ill-founded rumours - such as when a simple mention of 10,000 "parts kits" being on order caused some people to start thinking that the RasPi was not going to be fully assembled, simply because they didn't understand the meaning of that phrase in that context, and had not read the FAQ - and yet the RasPi team keep telling us what is going on because that is the ethos of the project.
I've got no association with the project, other than frank admiration at their dedication and focus on meeting their real goals, which is not to ship device X by time T, but to spark a renewed interest in the actual study and practise of computing.
Parent post hits nail squarely on head. Just because Random Hopeless CA X is still in a browser's trusted root CA list, should not mean that they can issue certs against my domain that anyone should trust. Placing signed cert public key fingerprints (or even the public key fingerprint of the root CA that actually issues your cert, if you really trust that CA) would make it much harder for an attacker to compromise a well-run, high-value web site (such as gmail.com or a banking web site).
Google did this unilaterally in their own browser, by only trusting the small set of CAs that Google uses when accessing its own web sites. Neat, but not at all scalable, even if Google were motivated to extend that feature to high-value web sites run by other companies.
Grid computing had a similar idea - if you wanted to get your CA's certificate into the bundle of trusted CAs distributed with common Grid software bundles like Globus or VDT, your CA had to have a "signing authority" that limited what certificate subjects it could sign for, which was part of the CA certificate. This meant that even if I compromised Random Trusted Grid CA X, I could not issue a cert that claimed I was from, say, Fermilab, because that cert would not match against the signing authority for that other Grid CA. Commercial CAs would never agree to similar provisions, because that would restrict who they could sell certs to, but the parent post's idea devolves that signing authority down to the people who actually pay for the certificate, which is naturally where that authority should reside.
Best of all, to implement this scheme, you just need to create an appropriate DNS record, add the check to your preferred open source web browser, and start selling the idea to the browser users and web site operators. With luck, the public support for the idea gets it adopted by web site operators (it costs them almost nothing), CAs have nothing to object to because they can still sell certs to whoever they were already selling certs to, and browser users put pressure on the developers to support the scheme. You don't have to persuade everyone to swallow a barrel of crypto-anarchist-libertarian "decentralise everything, storm the Winter Palace, power to the people, right on!" Kool-Aid and destroy the existing PKI CA architecture in order to save it.
Remember, politics is the art of the possible.
The creation of the universe is something wholly outside of all human experience, and no person who was ever born has ever had any personal knowledge or experience of anything coming out of nothing, so it's not really unreasonable for anyone to conclude that a nebula is actually many billions of years old based on that experience... But rational or not, such a conclusion based solely on that experience is really nothing more than rationalized self-deception.
It is also true that no person who was ever born has ever had any personal knowledge or experience of any impossible state of affairs. That does not make any impossible thing more possible just because we don't know what it would be like to experience that impossible thing. Or, indeed, help us work out which impossible thing would be more likely.
How about you work out a consensus "God(s) made everything we see just like so" story with all the other religions than the one you happen to cleave to? Because, by the same token you would not necessarily know how to recognise the world as a creation of Brahma, Eurynome and Ophion, Mazda, or the Flying Spaghetti Monster, rather than your god. Who knows, you might end up looking at the world to find evidence of a specific creation story. How would you weigh one religion's claim for justification based on one piece of evidence with other evidence that supports your preferred religion? Or different interpretations of the same evidence? You might need to develop some theories of natural science that let you tell the commonplace from the extraordinary. You will no doubt be relieved to find that there happen to be some quite useful theories of that sort knocking around already, that have been refined for many centuries. Feel free to use them to rationalise however much self-deception you need in order to elevate your creation story over all the others.
[...] He is not allowed to sit there and do nothing but watch TV. My wife plays and draws and bakes cookies and everything else you would expect a young child do.
I expected a lot from my young children, but I never expected them to bake cookies!
(My wife plays and draws and bakes cookies with my kids too, BTW... sorry, I just couldn't resist the exploitable typo :-)