As they store the data as images, there is no limit to what can be archived. I guess they just chose languages as the most important starting place, as presumably in the far flung future one might have decoded English, but be in possession of a treasure trove of documents written in Kanji that are utterly indecipherable without some sort of reference.
Probably the worst thing you can do is start with some complex clustered architectural design.
Just start on a single server with technologies that are scalable, and design with future scalability in mind. Also design in the ability to capture detailed performance metrics of every tier. When, and if your application usage grows, scale the parts of it that need scaling.
The biggest issue with scaling is usually the database, and for applications where you are just using the database as a simple persistence store for user settings and simple small data sets, you are probably best to go with one of the many scalable "NoSQL" type solutions such as MongoDB, as they've got scalability baked in for free. If you're trying to run heavy duty analytics that join and aggregate massive datasets, there are single DB clustering solutions, but they aren't cheap. You can always scale out SQL databases horizontally, but then you've got issues cloning and replicating, though there are a lot of products in that space, both free and commercial. A cheap place to start would be with PostgreSQL, which appears to have multiple open source replication products.
I don't think there is anything inherently limiting to sticking with Java. It's what you know, and the toolsets are deep and rich. No, it's not the hot new thing, but sometimes that can be a good thing.
I remember those heady days well. But over time slashdot's lost relevance to me. I stopped posting long ago as the quality of the discourse dropped, and I started linking directly to most of the sites slashdot regularly references. I also became unable (or unwilling) to comprehend the complicated comment filtering crud several years back (really, what's up with that?)
I do have slashdot to thank for helping me discover arstechnica - which has mostly replaced slashdot for my tech news discussion forum needs.
But still, I check slashdot daily.
Have fun Rob, enjoy your family, and find something new and interesting to do.
Just have the darned black box broadcast all of its data once every millisecond. Put receivers on satellites and on grounds stations or even on other planes. Give the transmitter a range of several thousand miles, and come up with some scheme to avoid broadcast collisions (either time or code division multiplexing).
If a plane goes down go back to the recorded transmissions, of which there should be multiple copies.
Converse All Stars. Don't know about high arches, but I too had foot pain at first after running in them. It subsided after awhile after the muscles, tendons and ligaments bulked up.
The reason you are experiencing pain is that one side of the thick wedges of foam in your shoe has lost it's spring, turning your shoe into a crappy little ramp that actually accentuates whatever that wedge was meant to correct.
The proper corrective for poor form is not a running shoe. It's either running barefoot, or running in a shoe with a thin rubber sole that serves as protection only. Try if for a month, but build your miles slowly. All the muscles, tendons and ligaments that your current shoes have allowed to atrophy will build up, and eventually you will be running like nature intended, with nearly perfect form.
You can protect your feet without slapping an inch thick slab of foam rubber under them.
I run in thin soled canvas shoes and have never had an injury from stepping on something. In fact I've had fewer ankle turn injuries as I can actually feel the surface and react if I've stepped on something that might cause my foot to slip or roll.
I code Android apps in my spare time. So basically I've got zero cost. Each of my apps has at least 3 competitors, which seem to be coded by people like me. Granted, many of my competitor's apps look like crap, but they work and provide a valuable service. Most people aren't going to pay top dollar for teh shiny - they are going to buy the cheapest thing that works. So I don't envision ever being able to charge a lot for my apps. I also don't see professional development shops being able to compete with zero cost hobbyists.
The apps are free because the Android market is in beta, and the payment system has not yet been activated. If I wanted to charge for the two apps I have in the Market right now I couldn't.
I don't know about whatever iPhone counterparts might exist for my apps, but they do what they do very well.
My apps run fine in the emulator at 320x480, no crashes.
Here is the deal, at 320x240, I go from 480 vertical pixels to 240. Ouch. Now I guess you could force the people who bought this new POS android phone to flip their phone sideways so that my app has 320 pixels - still quite a crunch - and have fun typing on this phone sideways.
But regardless, supporting such low resolution will take some doing on my part, and require me to maintain separate layouts, and possibly different code paths that reduce functionality or make other compromises. And at some point there are just some things that can't reasonably be done in half the screen real estate. I am likely not going to take the time to support such low screen resolutions in my apps.
I've developed two successful apps. One somewhat successful, one very successful. The most successful one is the most resolution independent. In coding it, I've done nothing that depends on any particular resolution. It randomly crashes in the emulator using QVGA (the resolution of the Aussie google phone). Even if it didn't crash, several of the screens are next to useless in the lower resolution, there is simply not enough space without recoding them.
Now, I could recode my app to use smaller fonts, lower the width/height of the UI components - but it would make my app less useful on the G1. Why would I want to do such a thing?
That's all well and good until I have to fit a certain amount of data on the screen. If I've designed for a larger screen, it's simply not going to fit, however flexible the layout.
Now I could design for the lowest possible screen resolution, but that will limit functionality or force me to produce a UI that's artificially small on larger screens.
Even the studious developers will have a lot of work to do making their apps work properly at lower resolutions.
It is sometimes *really* hard to make apps that work at all resolutions when you don't have much screen real estate. One of my apps will break horribly on this new screen layout, and I am not sure how to fix it. The other should work ok, but it won't be as usable, and will limit the amount of functionality. Detecting all this will be an utter nightmare.
My guess is that many of the android market apps will not work properly on this new phone.
This is what I like about the iPhone - there is *one* resolution and two orientations - that's it.
I didn't realize there is a version of Skype for Android. I've checked the Skype website to see if there were any announcements of such a beast, even tried a general Google for Skype for Android, and haven't seen it. Where'd you find Skype for Android? The closest thing I found was something called iSkoot, which doesn't appear to actually use Wifi?
Yes it is iSkoot, and you are right, it uses 3G, not wifi.
Not sure what they mean about a non-intuitive interface. What more freakin' intuitive than a physical keyboard?
Is "pinching" intuitive before somebody shows it to you. But I guess it's just an article of faith that anything not done by Apple must, by definition, be less intuitive than the Apple version.
On the useless but cool front - I made a skype-out call from the G1 over my wifi network today. Try that with an iPhone. Granted, it's a phone, so sure, what's the point. But it's good to know that even if I terminate my cell plan, the phone isn't a useless brick.
"All I know is that every large Java system seems to have parts written in native code called through the JNI."
I use several "large systems" written in Java that use no native code, other than what might be embedded in the JDK, and I imagine most of that is just string manipulation.
"A lot of people turn the native parts off though because they use ridiculous amounts of memory."
What the hell are you talking about? How does one "turn the native parts off" in Java? And why do you think these native bits use ridiculous amounts of memory?
He entirely ignores the fact that the earth has a somewhat finite surface area. At max we might be able to cover a few percent of the Earth's surface with solar cells (any more and we risk changing the Earth's albedo significantly), which catch usable sun for 8 hours a day on average. In space, surface area is unlimited, it's never cloudy, the sun shines 24/7, and the sun is twice as strong.
Yes, I explicitly state that the ISP would have to cooperate by running a proxy. So I register alice.com and point it at my ISP's proxy IP address. I also register my domain name with the ISP. Connections to alice.com get routed to the ISP proxy. The proxy inspects the "Host" header, looks it up in it's registry, and fowards to my current non-routable IP address.
For HTTP/S this works today with current equipment - in fact I would be suprised if there weren't ISPs doing it now.
You don't have to re-write the protocols, just tunnel them over HTTP/S.
We've been able to proxy a virtually unlimited number of web hosts using a single IP/port for over a decade by allowing routing information into the protocol itself via the "Host" header. Why does all routing formation have to be contained in the IP/Port? It doesn't.
We could design other protocols to contain routing information, or simply embed them in https, and allow forwarding based on domain names - which are never going to run out any time soon. There's no reason you couldn't run direct connect Skype this way, even if both users lack a public IP address - the ISP's router would just need to support forwarding based on the additional routing information contained in the protocol. If Skype made itself look like an https web server that supports persistent connections, it could be done with currently existing equipment.
Massive hack? Maybe. But a hell of a lot cheaper than implementing IPv6.
Sure, please define "broken". How is a browser supposed to know that the designer intended to position a div 100 pixels above where it's actually rendered?
To have any hope of surviving and being found in thousands of years, they need massive replication. Oh, I am sure they picked the best of materials, and they will last, but at $25,000 per, there just aren't going to be many of them left in 2,000 years because there weren't many of them made.
I would favor a cheaper mass produced product. Maybe something that on average doesn't have much hope of lasting more than a few hundred years, but if you make millions of them and shill them on the home shopping network - maybe somebody will have a hope of finding one in the distance future perfectly preserved in a redneck's hermetically sealed grave.
I'd suggest using something like a CD mastering process to stamp an analog message into a gold foil disk, that is then embedded in high quality, impact resistant glass. The glass seals against corrosion and moisture (if you are too cheap to go with the gold foil), and acts as a sacrificial surface that can take scratches bumps and dings and still be polished up by future archeologists.
No - what is wrong with this picture? Vista has failed to deliver a completely hack proof OS? Sorry to disappoint you - but I don't think anybody ever thought it was. It's certainly better than XP, even taking these new approaches into consideration.
Based on reading these, it seems the press is a bit overblown. The executive summary? While the newer Vista security provisions do make it harder to execute arbitrary code, there are still some exploitable holes, mostly because of legacy support, and the fact that some well known vendors still aren't compiling their code/plugins with the proper compiler switches.
Slashdot Mirror
As they store the data as images, there is no limit to what can be archived. I guess they just chose languages as the most important starting place, as presumably in the far flung future one might have decoded English, but be in possession of a treasure trove of documents written in Kanji that are utterly indecipherable without some sort of reference.
Check out the Rosetta Project - http://rosettaproject.org/about/
Probably the worst thing you can do is start with some complex clustered architectural design.
Just start on a single server with technologies that are scalable, and design with future scalability in mind. Also design in the ability to capture detailed performance metrics of every tier. When, and if your application usage grows, scale the parts of it that need scaling.
The biggest issue with scaling is usually the database, and for applications where you are just using the database as a simple persistence store for user settings and simple small data sets, you are probably best to go with one of the many scalable "NoSQL" type solutions such as MongoDB, as they've got scalability baked in for free. If you're trying to run heavy duty analytics that join and aggregate massive datasets, there are single DB clustering solutions, but they aren't cheap. You can always scale out SQL databases horizontally, but then you've got issues cloning and replicating, though there are a lot of products in that space, both free and commercial. A cheap place to start would be with PostgreSQL, which appears to have multiple open source replication products.
I don't think there is anything inherently limiting to sticking with Java. It's what you know, and the toolsets are deep and rich. No, it's not the hot new thing, but sometimes that can be a good thing.
I remember those heady days well. But over time slashdot's lost relevance to me. I stopped posting long ago as the quality of the discourse dropped, and I started linking directly to most of the sites slashdot regularly references. I also became unable (or unwilling) to comprehend the complicated comment filtering crud several years back (really, what's up with that?)
I do have slashdot to thank for helping me discover arstechnica - which has mostly replaced slashdot for my tech news discussion forum needs.
But still, I check slashdot daily.
Have fun Rob, enjoy your family, and find something new and interesting to do.
Just have the darned black box broadcast all of its data once every millisecond. Put receivers on satellites and on grounds stations or even on other planes. Give the transmitter a range of several thousand miles, and come up with some scheme to avoid broadcast collisions (either time or code division multiplexing).
If a plane goes down go back to the recorded transmissions, of which there should be multiple copies.
Converse All Stars. Don't know about high arches, but I too had foot pain at first after running in them. It subsided after awhile after the muscles, tendons and ligaments bulked up.
The reason you are experiencing pain is that one side of the thick wedges of foam in your shoe has lost it's spring, turning your shoe into a crappy little ramp that actually accentuates whatever that wedge was meant to correct.
The proper corrective for poor form is not a running shoe. It's either running barefoot, or running in a shoe with a thin rubber sole that serves as protection only. Try if for a month, but build your miles slowly. All the muscles, tendons and ligaments that your current shoes have allowed to atrophy will build up, and eventually you will be running like nature intended, with nearly perfect form.
You can protect your feet without slapping an inch thick slab of foam rubber under them.
I run in thin soled canvas shoes and have never had an injury from stepping on something. In fact I've had fewer ankle turn injuries as I can actually feel the surface and react if I've stepped on something that might cause my foot to slip or roll.
I code Android apps in my spare time. So basically I've got zero cost. Each of my apps has at least 3 competitors, which seem to be coded by people like me. Granted, many of my competitor's apps look like crap, but they work and provide a valuable service. Most people aren't going to pay top dollar for teh shiny - they are going to buy the cheapest thing that works. So I don't envision ever being able to charge a lot for my apps. I also don't see professional development shops being able to compete with zero cost hobbyists.
The apps are free because the Android market is in beta, and the payment system has not yet been activated. If I wanted to charge for the two apps I have in the Market right now I couldn't.
I don't know about whatever iPhone counterparts might exist for my apps, but they do what they do very well.
My apps run fine in the emulator at 320x480, no crashes.
Here is the deal, at 320x240, I go from 480 vertical pixels to 240. Ouch. Now I guess you could force the people who bought this new POS android phone to flip their phone sideways so that my app has 320 pixels - still quite a crunch - and have fun typing on this phone sideways.
But regardless, supporting such low resolution will take some doing on my part, and require me to maintain separate layouts, and possibly different code paths that reduce functionality or make other compromises. And at some point there are just some things that can't reasonably be done in half the screen real estate. I am likely not going to take the time to support such low screen resolutions in my apps.
I've developed two successful apps. One somewhat successful, one very successful. The most successful one is the most resolution independent. In coding it, I've done nothing that depends on any particular resolution. It randomly crashes in the emulator using QVGA (the resolution of the Aussie google phone). Even if it didn't crash, several of the screens are next to useless in the lower resolution, there is simply not enough space without recoding them.
Now, I could recode my app to use smaller fonts, lower the width/height of the UI components - but it would make my app less useful on the G1. Why would I want to do such a thing?
That's all well and good until I have to fit a certain amount of data on the screen. If I've designed for a larger screen, it's simply not going to fit, however flexible the layout.
Now I could design for the lowest possible screen resolution, but that will limit functionality or force me to produce a UI that's artificially small on larger screens.
Even the studious developers will have a lot of work to do making their apps work properly at lower resolutions.
It is sometimes *really* hard to make apps that work at all resolutions when you don't have much screen real estate. One of my apps will break horribly on this new screen layout, and I am not sure how to fix it. The other should work ok, but it won't be as usable, and will limit the amount of functionality. Detecting all this will be an utter nightmare.
My guess is that many of the android market apps will not work properly on this new phone.
This is what I like about the iPhone - there is *one* resolution and two orientations - that's it.
Why the hell aren't we putting nuclear batteries on these things?
I didn't realize there is a version of Skype for Android. I've checked the Skype website to see if there were any announcements of such a beast, even tried a general Google for Skype for Android, and haven't seen it. Where'd you find Skype for Android? The closest thing I found was something called iSkoot, which doesn't appear to actually use Wifi?
Yes it is iSkoot, and you are right, it uses 3G, not wifi.
Not sure what they mean about a non-intuitive interface. What more freakin' intuitive than a physical keyboard?
Is "pinching" intuitive before somebody shows it to you. But I guess it's just an article of faith that anything not done by Apple must, by definition, be less intuitive than the Apple version.
On the useless but cool front - I made a skype-out call from the G1 over my wifi network today. Try that with an iPhone. Granted, it's a phone, so sure, what's the point. But it's good to know that even if I terminate my cell plan, the phone isn't a useless brick.
"All I know is that every large Java system seems to have parts written in native code called through the JNI."
I use several "large systems" written in Java that use no native code, other than what might be embedded in the JDK, and I imagine most of that is just string manipulation.
"A lot of people turn the native parts off though because they use ridiculous amounts of memory."
What the hell are you talking about? How does one "turn the native parts off" in Java? And why do you think these native bits use ridiculous amounts of memory?
He entirely ignores the fact that the earth has a somewhat finite surface area. At max we might be able to cover a few percent of the Earth's surface with solar cells (any more and we risk changing the Earth's albedo significantly), which catch usable sun for 8 hours a day on average. In space, surface area is unlimited, it's never cloudy, the sun shines 24/7, and the sun is twice as strong.
Yes, I explicitly state that the ISP would have to cooperate by running a proxy. So I register alice.com and point it at my ISP's proxy IP address. I also register my domain name with the ISP. Connections to alice.com get routed to the ISP proxy. The proxy inspects the "Host" header, looks it up in it's registry, and fowards to my current non-routable IP address.
For HTTP/S this works today with current equipment - in fact I would be suprised if there weren't ISPs doing it now.
You don't have to re-write the protocols, just tunnel them over HTTP/S.
We've been able to proxy a virtually unlimited number of web hosts using a single IP/port for over a decade by allowing routing information into the protocol itself via the "Host" header. Why does all routing formation have to be contained in the IP/Port? It doesn't.
We could design other protocols to contain routing information, or simply embed them in https, and allow forwarding based on domain names - which are never going to run out any time soon. There's no reason you couldn't run direct connect Skype this way, even if both users lack a public IP address - the ISP's router would just need to support forwarding based on the additional routing information contained in the protocol. If Skype made itself look like an https web server that supports persistent connections, it could be done with currently existing equipment.
Massive hack? Maybe. But a hell of a lot cheaper than implementing IPv6.
Sure, please define "broken". How is a browser supposed to know that the designer intended to position a div 100 pixels above where it's actually rendered?
To have any hope of surviving and being found in thousands of years, they need massive replication. Oh, I am sure they picked the best of materials, and they will last, but at $25,000 per, there just aren't going to be many of them left in 2,000 years because there weren't many of them made.
I would favor a cheaper mass produced product. Maybe something that on average doesn't have much hope of lasting more than a few hundred years, but if you make millions of them and shill them on the home shopping network - maybe somebody will have a hope of finding one in the distance future perfectly preserved in a redneck's hermetically sealed grave.
I'd suggest using something like a CD mastering process to stamp an analog message into a gold foil disk, that is then embedded in high quality, impact resistant glass. The glass seals against corrosion and moisture (if you are too cheap to go with the gold foil), and acts as a sacrificial surface that can take scratches bumps and dings and still be polished up by future archeologists.
No - what is wrong with this picture? Vista has failed to deliver a completely hack proof OS? Sorry to disappoint you - but I don't think anybody ever thought it was. It's certainly better than XP, even taking these new approaches into consideration.
Based on reading these, it seems the press is a bit overblown. The executive summary? While the newer Vista security provisions do make it harder to execute arbitrary code, there are still some exploitable holes, mostly because of legacy support, and the fact that some well known vendors still aren't compiling their code/plugins with the proper compiler switches.