We could probably have a more detailed discussion looking at the actual source. That's one of the advantages of Open Source. There's some good advice here already, but for what you're doing I would lean heavily on making it as easy and painless as possible to recover from an incident. Let's say you have a major incident.
If you run it all in a VM you'll lose some performance, but you can snapshot it, kill it and ship the snapshot to a local machine for forensics while directing everyone to a "Maintenance in Progress" page. When you're ready to come back up you can restore from a previous snapshot apply the patches that fix the hole and move on with life.
Obviously game state makes this harder, so alot depends on what you can do to make the app support this.
Anyway, your project sounds cool. I'd like to see it.
At least according to Ben Lorica at O'Reilly Research. At the time of that post at least, the US made up about 35% of Facebook users, and the US and UK and Candada together made up about 61%. The US still had the most for a single country, but that's a long way from being the majority.
Actually just moving your mouse should have panned the screen. There may be another problem. Yes you can press the ALT key and click on a window to move it in Gnome, but you shouldn't have to. (BTW those things also work in similar ways on Windows and Mac).
(Change an Ubuntu screen to 640x480, and then try to change it back, without using secret hidden commands. Can't be done.)
It not only can be done, but you actually do it just about the same way as with Mac or Windows. Just go to the menu on the toolbar.
Look under System => Preferences => Screen Resolution
How is that harder than doing the same thing in Mac or Windows?
That's what Linux needs to become if it wants to be a universal replacement desktop, instead of just an isolated tool for technicians.
Then get to work.
Linux is your operating system too. Why not start a project to build a desktop that works the way you want it? You don't have to be a developer. If you have ideas compelling enough, you can probably rope in a few coders to knock out a prototype and attract some interest.
Really, after even getting one book out the door, the very next question from any publisher is likely to be "What else do you have?" Even if you haven't ever published a book before you can do exactly what you described right here. Just follow the guidelines to the letter and you will get a fair reading, or that was my experience. I nearly fell over when they accepted my proposal, and this is just how I did it.
My experience publishing a book with O'Reilly was just about perfect. The editors were smart, well-informed and deep enough to catch even binary encoding typos in protocol descriptions, and even though my coauthor and I had looked for critique by just everyone we could talk into it, the mandatory peer review process gave us a great chance to hear what people who had no vested interest in protecting our feelings had to say about the book in its nearly finished form. We made significant changes for the better from the editors' edits and suggestions and peer review questions and criticism. I would recommend O'Reilly to anyone with a technical book.
One thing to be aware of, O'Reilly prefers to start from scratch rather than getting a completed manuscript. They have very strict submission guidelines (down to specific styles in the document) that feed into their automated typesetting process. It's worth the effort to do it their way, because it eliminates plenty of opportunities for error and confusion.
I'm a big fan of calm. I prefer it, but the "zombie like" lack of affect that posters have described for people taking lithium is on an entirely different level than "calm." I have a family member who was on lithium as part of the "shotgun medicine" approach to bipolar disorder, and it was heartbreaking to watch. Later, she described the sensation as being unable to feel any emotion or emotional connection at all, but that was at the current therapeutic doses. I'm with the posters that wonder if this study might be a first indication that we should study the effects of lower doses. And the idea that it's really a deficiency is intriguing.
I'll agree it's a stretch to compare EC2 to Citigroup, but the concern is valid. I think a better comparison would be to mainframe timeshares. There were several reasons buying time on a mainframe was less desirable than distributed computing. Open APIs are better than vendor lock-in for the consumer, end of story.
But one comparison to the banks is worth making, imagine for a moment that Amazon or Google did take a financial hit or make a bad decision that lead to them shutting down their grid offerings. It would be difficult to move the app and management tools to new hosting without some standardization.
The trick is probably to build another layer that abstracts the EC2 management and Google App Engine stuff and only write to the common API, then encourage other hosting providers to support that common API, or just convince Google or Amazon to support a common API in the first place. They have the scale and experience to compete on price and performance.
It's actually a pretty attractive open source project, take maybe the open source Sun Grid Engine and XEN as a start and build out a grid offering equivalent to EC2 for hosting providers.
This reads exactly like the back story of a zombie apocalypse novel. Still this is a massively useful development in AI. It's an automated phenotype sequencer!:)
I think you missed which side of that story you fall on. I believe he meant folks who were born in the 1940's and 1950's who would now be in their 60's and 70's. Folks born in the 1960's and later grew up with computers, and so would not be in the poster described.
He's talking about the experience that my generation had coming into computing where only the youngsters "got it." Now we're in our 40's and 50's, and many of us still work in IT related jobs, so the apparent ageism is fading.
When I started working at my present company, they had an old Unicomp keyboard lying around that no one else wanted to use. I was happy to give it try. I love the way it feels to my fingers and it definitely improved my typing speed and accuracy. I'm a heavy emacs user, and I appreciate that the Ctrl key is as solid and responsive today as it was months ago. This is the first keyboard I've had that could stand up to heavy coding and writing.
The noise made me feel a little self conscious at first but my neighbors are used to it, and the guy in the next cube tried mine out and ordered his own. He's as happy with his as I am with mine, but he ordered the Mac caps to switch out.
I run an Iogear USB/DVI and switch between three Linux boxes, a Mac Pro and a Windows XP box and all work great with the Unicomp as well.
I ran a Telegard (and later Renegade) board, but I enjoyed visiting the Roboterm boards in town. I really miss the sound of that modem connect sometimes.
Does anyone else remember Roboterm? It was a graphical BBS terminal client (which would show downloaded graphics when talking to a roboterm board). Neat but proprietary:
I'll second what bbutton said about scheduling, time, version control and the experience. Writing RFID Essentials for O'Reilly was hard but very rewarding, I recommend them as a publisher if you don't already have one.
If you are working with O'Reilly they will want you to use their style templates from the beginning and will want to work with you section by section. Their templates a few years ago worked best with Word, but OpenOffice support was coming along fast and may be complete now. A books starts with a proposal and a chapter sample for O'Reilly.
If you are working with another publisher they will probably want a complete first draft. Typed, double-spaced, manuscript format, with text to indicated where the graphics will be.
If you don't have a publisher yet. Most will want a query letter and sample chapter before you send them a completed manuscript, but they will expect you to have a completed manuscript.
A note on graphics. Your own drawings and graphs will probably be replaced by professional artwork so be prepared to go a few rounds to get them right. What seems obvious to you won't necessarily be obvious to even a technically savvy artist with a heavy workload.
And be sure to start gathering citation information and copyright releases now for images and quotes. You'll need permission for everything and it can take time to get a response.
Whoever you work with, expect the book to change significantly from first draft to final as you find ways to refine it, and don't be afraid to interview the biggest names in your field. Always record the interview for accuracy and send them a recording or transcript along with the release form. A good rule of thumb is to interview anyone who you think would be a tough critic for the book, or who you think is just too important to talk to you. You'll be surprised how helpful they will be, and the book will be better for it. You will be more confident you've been fair about addressing their arguments when the book is published.
Most publishers will also hire independent experts in your field to peer review the book and make sure it's ready for the public. O'Reilly is especially good about this, and their feedback will help you catch some of the subtle errors that creep in over a long hard writing process.
A personal note: If you are sane human being you will want to give the whole thing up several times before you're done. Don't give up. It really is amazing to see your book in print and you will be stunned at the kind of positive impact you can have on other people's lives just by getting the facts right and making something easier to understand. There is also a rush like nothing else when the words are coming out right and you're flowing.
Best of luck and congratulations on starting the adventure.
But a rocket hook combination makes the most sense right now, it would reduce the launch weight by removing the need for the vehicle to accelerate itself all the way to orbital velocity.
Listen to what the parent is saying, folks. It's the difference between freedom and dictatorship, and apparently a principal that some portion of the population in the US and UK don't understand.
Let's just all use 24 hour UTC. Who cares if sunrise is at 12:00? Or better yet use a decimal system. Why are we still using a base 60 system invented by the Sumerians?
I have a 5 digit Slashdot ID, so I think you can count on me being a reliable source. I got the information from a Slashdot story as well, so you can be pretty certain it's completely accurate.
I have a 4 digit Slashdot ID and I vouch for the absolute veracity of the parent, so don't bother fact checking, or I'll go crying to one of the 3 digiters and they'll show you what for.
The whole point of SL is user created (and owned) content. Sony and MS both missed the point, or the article missed it by drawing a comparison between animated chat avatars SL. What Linden did was alot harder. They have to deal with a continuous world (no fragments) entirely made up of user generated content with no chance to pre-calc or optimize before rendering. It's a bit like comparing Pidgin to Python.
We could probably have a more detailed discussion looking at the actual source. That's one of the advantages of Open Source. There's some good advice here already, but for what you're doing I would lean heavily on making it as easy and painless as possible to recover from an incident. Let's say you have a major incident.
If you run it all in a VM you'll lose some performance, but you can snapshot it, kill it and ship the snapshot to a local machine for forensics while directing everyone to a "Maintenance in Progress" page.
When you're ready to come back up you can restore from a previous snapshot apply the patches that fix the hole and move on with life.
Obviously game state makes this harder, so alot depends on what you can do to make the app support this.
Anyway, your project sounds cool. I'd like to see it.
At least according to Ben Lorica at O'Reilly Research. At the time of that post at least, the US made up about 35% of Facebook users, and the US and UK and Candada together made up about 61%. The US still had the most for a single country, but that's a long way from being the majority.
In other words you can't be bothered. That's you. Thanks for sharing.
Actually just moving your mouse should have panned the screen. There may be another problem. Yes you can press the ALT key and click on a window to move it in Gnome, but you shouldn't have to. (BTW those things also work in similar ways on Windows and Mac).
(Change an Ubuntu screen to 640x480, and then try to change it back, without using secret hidden commands. Can't be done.)
It not only can be done, but you actually do it just about the same way as with Mac or Windows. Just go to the menu on the toolbar.
Look under System => Preferences => Screen Resolution
How is that harder than doing the same thing in Mac or Windows?
That's what Linux needs to become if it wants to be a universal replacement desktop, instead of just an isolated tool for technicians.
Then get to work.
Linux is your operating system too. Why not start a project to build a desktop that works the way you want it? You don't have to be a developer. If you have ideas compelling enough, you can probably rope in a few coders to knock out a prototype and attract some interest.
What would you start with?
Really, after even getting one book out the door, the very next question from any publisher is likely to be "What else do you have?" Even if you haven't ever published a book before you can do exactly what you described right here. Just follow the guidelines to the letter and you will get a fair reading, or that was my experience. I nearly fell over when they accepted my proposal, and this is just how I did it.
My experience publishing a book with O'Reilly was just about perfect. The editors were smart, well-informed and deep enough to catch even binary encoding typos in protocol descriptions, and even though my coauthor and I had looked for critique by just everyone we could talk into it, the mandatory peer review process gave us a great chance to hear what people who had no vested interest in protecting our feelings had to say about the book in its nearly finished form. We made significant changes for the better from the editors' edits and suggestions and peer review questions and criticism. I would recommend O'Reilly to anyone with a technical book.
One thing to be aware of, O'Reilly prefers to start from scratch rather than getting a completed manuscript. They have very strict submission guidelines (down to specific styles in the document) that feed into their automated typesetting process. It's worth the effort to do it their way, because it eliminates plenty of opportunities for error and confusion.
well the same thing as always. forth ;)
You aren't looking very closely if you're missing it.
By "c-like" I believe Graham meant elements of syntax and approach.
methods declarations in Java take the form:
return_value name(args)
{
statement;
data_structure.member = assignment;
}
A C function looks like:
return_value name(args)
{
statement;
data_structure.member = assignment;
}
The approach stuff is harder to summarize in a post but think of the differences in the use of macros and differences in binding as good examples
James Gosling is one of the people who called Java a "C-like language that avoided the pitfalls of C++"
(full disclosure: I used to work for Sun as a Senior Java Architect so my opinion may colored by the chip they put in my brain)
I'm a big fan of calm. I prefer it, but the "zombie like" lack of affect that posters have described for people taking lithium is on an entirely different level than "calm." I have a family member who was on lithium as part of the "shotgun medicine" approach to bipolar disorder, and it was heartbreaking to watch. Later, she described the sensation as being unable to feel any emotion or emotional connection at all, but that was at the current therapeutic doses. I'm with the posters that wonder if this study might be a first indication that we should study the effects of lower doses. And the idea that it's really a deficiency is intriguing.
I'll agree it's a stretch to compare EC2 to Citigroup, but the concern is valid. I think a better comparison would be to mainframe timeshares. There were several reasons buying time on a mainframe was less desirable than distributed computing. Open APIs are better than vendor lock-in for the consumer, end of story.
But one comparison to the banks is worth making, imagine for a moment that Amazon or Google did take a financial hit or make a bad decision that lead to them shutting down their grid offerings. It would be difficult to move the app and management tools to new hosting without some standardization.
The trick is probably to build another layer that abstracts the EC2 management and Google App Engine stuff and only write to the common API, then encourage other hosting providers to support that common API, or just convince Google or Amazon to support a common API in the first place. They have the scale and experience to compete on price and performance.
It's actually a pretty attractive open source project, take maybe the open source Sun Grid Engine and XEN as a start and build out a grid offering equivalent to EC2 for hosting providers.
This reads exactly like the back story of a zombie apocalypse novel. Still this is a massively useful development in AI. It's an automated phenotype sequencer! :)
I think you missed which side of that story you fall on. I believe he meant folks who were born in the 1940's and 1950's who would now be in their 60's and 70's. Folks born in the 1960's and later grew up with computers, and so would not be in the poster described.
He's talking about the experience that my generation had coming into computing where only the youngsters "got it." Now we're in our 40's and 50's, and many of us still work in IT related jobs, so the apparent ageism is fading.
When I started working at my present company, they had an old Unicomp keyboard lying around that no one else wanted to use. I was happy to give it try. I love the way it feels to my fingers and it definitely improved my typing speed and accuracy. I'm a heavy emacs user, and I appreciate that the Ctrl key is as solid and responsive today as it was months ago. This is the first keyboard I've had that could stand up to heavy coding and writing.
The noise made me feel a little self conscious at first but my neighbors are used to it, and the guy in the next cube tried mine out and ordered his own. He's as happy with his as I am with mine, but he ordered the Mac caps to switch out.
I run an Iogear USB/DVI and switch between three Linux boxes, a Mac Pro and a Windows XP box and all work great with the Unicomp as well.
There's a link for binaries at the same site as the review. I haven't tried them, but it's a place to start.
I ran a Telegard (and later Renegade) board, but I enjoyed visiting the Roboterm boards in town. I really miss the sound of that modem connect sometimes.
Does anyone else remember Roboterm? It was a graphical BBS terminal client (which would show downloaded graphics when talking to a roboterm board). Neat but proprietary:
I'll second what bbutton said about scheduling, time, version control and the experience.
Writing RFID Essentials for O'Reilly was hard but very rewarding, I recommend them as a publisher if you don't already have one.
If you are working with O'Reilly they will want you to use their style templates from the beginning and will want to work with you section by section. Their templates a few years ago worked best with Word, but OpenOffice support was coming along fast and may be complete now. A books starts with a proposal and a chapter sample for O'Reilly.
If you are working with another publisher they will probably want a complete first draft. Typed, double-spaced, manuscript format, with text to indicated where the graphics will be.
If you don't have a publisher yet. Most will want a query letter and sample chapter before you send them a completed manuscript, but they will expect you to have a completed manuscript.
A note on graphics. Your own drawings and graphs will probably be replaced by professional artwork so be prepared to go a few rounds to get them right. What seems obvious to you won't necessarily be obvious to even a technically savvy artist with a heavy workload.
And be sure to start gathering citation information and copyright releases now for images and quotes. You'll need permission for everything and it can take time to get a response.
A nice summary on what to do:
http://oreilly.com/oreilly/author/permission/
Whoever you work with, expect the book to change significantly from first draft to final as you find ways to refine it, and don't be afraid to interview the biggest names in your field. Always record the interview for accuracy and send them a recording or transcript along with the release form. A good rule of thumb is to interview anyone who you think would be a tough critic for the book, or who you think is just too important to talk to you. You'll be surprised how helpful they will be, and the book will be better for it. You will be more confident you've been fair about addressing their arguments when the book is published.
Most publishers will also hire independent experts in your field to peer review the book and make sure it's ready for the public. O'Reilly is especially good about this, and their feedback will help you catch some of the subtle errors that creep in over a long hard writing process.
A personal note: If you are sane human being you will want to give the whole thing up several times before you're done. Don't give up. It really is amazing to see your book in print and you will be stunned at the kind of positive impact you can have on other people's lives just by getting the facts right and making something easier to understand. There is also a rush like nothing else when the words are coming out right and you're flowing.
Best of luck and congratulations on starting the adventure.
A rotating skyhook (a rotating line connected to a ballast on one end and a payload on the other) wouldn't have that problem.
http://www.nss.org/settlement/L5news/1983-skyhook.htm
But a rocket hook combination makes the most sense right now, it would reduce the launch weight by removing the need for the vehicle to accelerate itself all the way to orbital velocity.
Tower Defense in javascript
http://ejohn.org/blog/processingjs-tower-defense/
Listen to what the parent is saying, folks. It's the difference between freedom and dictatorship, and apparently a principal that some portion of the population in the US and UK don't understand.
The UK is doing better lately.
The US has further to go to get back on track:
Let's just all use 24 hour UTC. Who cares if sunrise is at 12:00? Or better yet use a decimal system. Why are we still using a base 60 system invented by the Sumerians?
A twist on the same idea: Fabjectory makes RL 3D models of objects and avatars from Second Life, Google Sketch Up and Nintendo Mii.
It's a much cooler system that ends up as a plaster, colored model.
They don't mention how much it costs though, so I'm thinking it's expensive.
I have a 5 digit Slashdot ID, so I think you can count on me being a reliable source. I got the information from a Slashdot story as well, so you can be pretty certain it's completely accurate.
I have a 4 digit Slashdot ID and I vouch for the absolute veracity of the parent, so don't bother fact checking, or I'll go crying to one of the 3 digiters and they'll show you what for.
The whole point of SL is user created (and owned) content. Sony and MS both missed the point, or the article missed it by drawing a comparison between animated chat avatars SL. What Linden did was alot harder. They have to deal with a continuous world (no fragments) entirely made up of user generated content with no chance to pre-calc or optimize before rendering. It's a bit like comparing Pidgin to Python.