How about developing a standard medical record access protocol. Companies can compete to store your information. They would compete based on who guards the information best. A service is defined via URL. So if you want to grant a hospital access to your records, you supply the URL and credentials (maybe a key/certificate stored on a card). They use a standard access protocol to fetch and/or update the data. The standard may also define how the client (hospital) may access the records, preventing a leak from that side.
On the client side, a dedicated machine would be a good idea. No web browsers or email clients installed, nor any other software that isn't necessary for interfacing with the medical records services. Strip it down and guard it enough so that there's no need for AV or other half-measures. For example, at the OS level there could be a whitelist of URLs accessible by the client application.
My year + old Nokia running Maemo 5 (N900) is pretty nice and holds its own against my wife's 4G iPhone. The non-OSS app selection isn't very good, but neither is WP7. So Maemo 5 was decent over 1 year ago and it's going to take Nokia at least a year to switch to WP7. That's 2 years to work on Maemo. And when they're done, it's theirs.
There's so many things wrong with the WP7 decision, but the biggest is this: Nokia will be relegated to just another WP7 handset maker. They can't differentiate themselves. And IF MS GOOFS ON WP7, be it security decisions or bad design decisions, Nokia goes down with them. Going with WP7 takes the control out of their hands and puts it in Microsoft's.
We're sorry, but your operating system is not supported. Please purchase a copy of Government Sanctioned Monopoly Co. OS and come back.
AV works so well now anyway. I just cleaned off several viruses from a laptop Microsoft Security Essentials said was clean. All you AV proponents, run a Linux distro or OS X for a few months and you'll change your mind. It's amazing how fast modern computers are when they're not bogged down to 1990 era speeds by AV.
... would be brutally competitive, low margin.... Any of the other options, save MS, would consign them to the Nokia ghetto, with few apps, no significant community.
low margin - So how is WP7 going to give them better margins than Android when they can't customize it or otherwise differentiate themselves from other WP7 phones?
Nokia ghetto, with few apps - Um, since when did WP7 have a nice app ecosystem? I think you mixed up Androids app ecosystem with WP7's.
no significant community - Again, like the apps. What are you smoking? WP7 - community. Ha! Maemo has a better community than WP7 maemo.org
If you switched Android and WP7 in your argument, it would make sense. How did so many people mark this insightful?
And Android is just Linux with a nice UI. And iOS is just BSD with a nice UI. Oh, and the iPod was way too late. That market was already saturated. Same for the iPhone. No way some computer company can enter the well established and populated cell phone market.
Not 99%. You don't need to dominate the market to make a profit. That's Microsoft's way of thinking. You need just enough for a market niche. I for one bought an N800 and N900 and will buy the next device that grants the same level of freedom and functionality.
If for no other reason, it's a bad idea to use Windows (or any proprietary OS) because the functionality should be 100% reviewable. Black boxes are a really, really bad idea in critical systems.
I ran into problems with duplicates over the years from copying files off my laptop before installing a new OS and for other reasons. I used dupmerge, which identifies the duplicate files and uses hardlinks to keep only a single copy. Freed up quite a bit of space for me.
We've been there before and it didn't work out so well. Remember RealPlayer and Quicktime. On most systems flash is a dog, yet we use it instead of handing off to OS installed programs. That makes it clear that users and developers prefer to use a solution that is sure to work over one that may be better, but might not be available. In this case h.264 might be better than say, webm, but its proprietary nature will prevent it from being installed on the majority of systems, especially now that there is a healthy browser ecosystem. webm is good. Maybe not as good as h.264, but it is sufficient for a standard, and that's what we need - a standard.
Note that there is a big difference from this and what you're speaking of. The satellites you're speaking of are 23,000 miles up. Adding in round trips for TCP confirmation gives you something like 500 ms latency. Low orbit satellites, being almost 40 times closer have latencies closer to 10 ms, which is pretty good. The reclamation was addressed in the summary, which I'm guessing you stopped short of reading.
The company likes to spotlight its competition with the O3b, the Google-backed satellite project to improve Net access for the 3 billion people who live outside of wealthy, well-wired areas.
Sounds like more options and much needed competition on the way. If it's not tied to another service the way DSL, Cable, and Cell service is, it could heat up the ISP market. I do wonder if and how RF saturation might limit the market potential for this tech.
We need MPEG-LA specifically because it puts an end to bullshit like this.
We have MPEG-LA and it obviously doesn't put an end to bullshit like this. What we need is to abolish the software patents that got us here in the first place.
To be more specific, more software has been written for win32 than all other platforms combined. But, we're talking about tablets here. And for the kind with no keyboard or mouse, win32 apps do not run well, because their interface doesn't work. That should be clear after the failure of previous Windows tablets and the success of the iPad. So if we're talking about iPad competitors, win32 application compatibility it irrelevant.
As much as I agree that programmers tend to overestimate their importance -- a trait that pretty much every job category shares to one degree or another -- I think the idea is of negligible importance compared to the marketing.
Marketing is most important? I guess that depends on what you value. Maybe for maximizing profits. Consider what happens when a terrible movie gets marketed heavily. It still flops as soon as the first wave of duped people watch it and get the word out.
What's important is progress, and that comes from good ideas followed up with good implementations. And you don't have to be a magnate to see this.
Most everyone doesn't want a phone where they "have" to tweak it to get it to do what it is supposed to do. No being "interested" is different though. A geek (Slashdot target audience - NEWS FOR NERDS) will certainly be interested. I have a life outside of programming/computers, but I'm still addicted to it. I do it even when it does not make sense time or money wise, because I enjoy it. It's like any other hobby or passion. BTW, iOS and Android are too closed for me. I use an N900.
You described the issue with instantaneous capacity that has always been a problem for cellular communication, but that doesn't explain the 5GB limit. I'm sure most users would rather be connected all of the time, some or most of it being at less than the maximum data rate rather than to use their LTE service at full speed for a few days and then have to cease usage completely because they hit the 5 GB limit.
Don't just factor dose. Consider the intensity also. That is one of Bruce's points. As an analogy, consider getting hit by 1000 gallons of water from a garden hose vs 1000 gallons from a fire hose. Same dose, different intensity. Add to that the dose being delivered to the skin instead of being distributed throughout the body.
My experience has been similar to yours. I agree with you about the issues that exist, though I don't agree with your prescription to use only the basic features. ORM can drastically reduce code complexity and still perform well if you are willing to properly learn how to use the library and understand performance trade-offs. The main problem is that most people aren't willing to put in the time and effort (as with most everything in life).
Some tips.
Make sure you have a good database design to begin with.
Turn on logging so that you can see the SQL statements issued. Are you pulling every field from a table when all you need is one? Are you selecting from related tables that aren't needed. Not everything need be done is the most efficient manner, but consider where optimizations can and should be performed.
Automated tests. Test your data model to make sure it performs both properly and efficiently.
When using ORM, you have do have to pay attention to what's happening underneath. It's a trade-off, but in the end your code is much more simple and portable. After spending time with an ORM, surprise, you learn how to use it better.
Salts protect against rainbow tables, not necessarily short passwords. In most situations, the salt needs to be known by both parties and is sent in the transmission so that the salt is not a secret. Don't count on the salt being a secret. You still need to choose a good password. Using a salt just means an attacker won't be able to look up the hash in a rainbow table.
Nokia has been supporting Maemo as an also run Windows mobile type smart phone OS for a long time, and having iPhone, Android, WebOS, and WP7 absolutely blow their offerings out of the water means that something had to change with them. I'm not sure why they just can't pull something compelling together, but its hurting the company until they work on getting something. I personally think that bringing in Qt was a bad decision which has at least in a small part hindered efforts to get product to market.
I agree with everything else but this. Have you used an N900? Maemo is the most capable of the mobile OS's and it's a solid progression from the previous versions. The interface is slick - four desktops with useful widgets, combined IM/SMS/SIP "conversations", nice view of multiple running apps and more. The reasons it's niche is because Nokia has not aimed Maemo at the general public, but instead has targeted a small geek market. In fact the N900 is marketed as a mobile computer, not a phone. I'll bet their next Maemo or Meego offering will be a smart phone.
Qt has long surpassed GTK and since Nokia owns the company they'd be nuts not to use it. From what I can tell they've done a fine job of transitioning developers.
Productive, predictable concurrency is possible in Java and not in many other languages
I don't buy that for second. I've written enough multi-threaded and multi-process applications in Python to know that it works well. That is, Python facilitates productive, predictable concurrency. I'll give you the GIL issue, which prevents maxing out multiple CPUs for CPU intensive multi-threaded tasks, but it's not an issue for threading IO (disk and network) bound tasks. And for processor heaving concurrent tasks, the multiprocessing module is well suited.
Java includes a lot of well-organized, stable libraries for doing everything from handling HTTP requests and crafting responses to doing cryptography. Its collections API has many data structures that just aren't present in other languages without looking to a third party.
Python has that too. In fact, its native list and dict types take care of most needs. Although there is a collections module too - no third party software needed. Cryptography has been blocked by the U.S.'s stupid export laws. Pycrypto is available for crypto needs.
Finally, the JVM makes naive code fast. One can write reasonably expressive, straightforward code and expect that the hotspot compiler will optimize it. It's a boon for getting maintainable, quality code out-the-door quickly.
I don't think this gives Java much advantage. Python is arguably more expressive and readable. Everyone here has their own experience they will draw on. Mine has been that although the JVM is much faster, the programs written in Python are at least fast enough, as fast, or sometimes even faster than the Java equivalent. I think this is because often times, much of the processing for Python apps is handled by modules written in C. Anyway, the issues I've run into haven't included apps running too slowly and the "expressive and readable" part are more important to me.
The argument isn't about the license, it's about patents. At any time, MS could step in and say that they own patents essential to the Mono implementation. That's why people are cautious about Mono and why most steer clear of it.
I think you're being too harsh. I looked at the script and it's very short and fairly easy to read. How can you complain about that? I couldn't get to the website to download the Windows tool, but I'm going to guess it's a compiled exe (could be wrong), which means it's not easy for the user to edit. By contrast, the user can easily tailor the Python script to fit their needs. In addition, the script also serves as format documentation. He clearly commented sections such as "daily record", "error record" and "1 second record".
Slashdot Mirror
How about developing a standard medical record access protocol. Companies can compete to store your information. They would compete based on who guards the information best. A service is defined via URL. So if you want to grant a hospital access to your records, you supply the URL and credentials (maybe a key/certificate stored on a card). They use a standard access protocol to fetch and/or update the data. The standard may also define how the client (hospital) may access the records, preventing a leak from that side.
On the client side, a dedicated machine would be a good idea. No web browsers or email clients installed, nor any other software that isn't necessary for interfacing with the medical records services. Strip it down and guard it enough so that there's no need for AV or other half-measures. For example, at the OS level there could be a whitelist of URLs accessible by the client application.
My year + old Nokia running Maemo 5 (N900) is pretty nice and holds its own against my wife's 4G iPhone. The non-OSS app selection isn't very good, but neither is WP7. So Maemo 5 was decent over 1 year ago and it's going to take Nokia at least a year to switch to WP7. That's 2 years to work on Maemo. And when they're done, it's theirs.
There's so many things wrong with the WP7 decision, but the biggest is this: Nokia will be relegated to just another WP7 handset maker. They can't differentiate themselves. And IF MS GOOFS ON WP7, be it security decisions or bad design decisions, Nokia goes down with them. Going with WP7 takes the control out of their hands and puts it in Microsoft's.
We're sorry, but your operating system is not supported. Please purchase a copy of Government Sanctioned Monopoly Co. OS and come back.
AV works so well now anyway. I just cleaned off several viruses from a laptop Microsoft Security Essentials said was clean. All you AV proponents, run a Linux distro or OS X for a few months and you'll change your mind. It's amazing how fast modern computers are when they're not bogged down to 1990 era speeds by AV.
... would be brutally competitive, low margin. ... Any of the other options, save MS, would consign them to the Nokia ghetto, with few apps, no significant community.
If you switched Android and WP7 in your argument, it would make sense. How did so many people mark this insightful?
And Android is just Linux with a nice UI. And iOS is just BSD with a nice UI. Oh, and the iPod was way too late. That market was already saturated. Same for the iPhone. No way some computer company can enter the well established and populated cell phone market.
You're not late when you bring the good stuff.
I think that's gonna be my new sig.
Not 99%. You don't need to dominate the market to make a profit. That's Microsoft's way of thinking. You need just enough for a market niche. I for one bought an N800 and N900 and will buy the next device that grants the same level of freedom and functionality.
If for no other reason, it's a bad idea to use Windows (or any proprietary OS) because the functionality should be 100% reviewable. Black boxes are a really, really bad idea in critical systems.
Which further proves his point. Bringing in an American MS guy is not in line with the aforementioned strategy.
I ran into problems with duplicates over the years from copying files off my laptop before installing a new OS and for other reasons. I used dupmerge, which identifies the duplicate files and uses hardlinks to keep only a single copy. Freed up quite a bit of space for me.
We've been there before and it didn't work out so well. Remember RealPlayer and Quicktime. On most systems flash is a dog, yet we use it instead of handing off to OS installed programs. That makes it clear that users and developers prefer to use a solution that is sure to work over one that may be better, but might not be available. In this case h.264 might be better than say, webm, but its proprietary nature will prevent it from being installed on the majority of systems, especially now that there is a healthy browser ecosystem. webm is good. Maybe not as good as h.264, but it is sufficient for a standard, and that's what we need - a standard.
You mean a force component, right? http://en.wikipedia.org/wiki/Pressure
Note that there is a big difference from this and what you're speaking of. The satellites you're speaking of are 23,000 miles up. Adding in round trips for TCP confirmation gives you something like 500 ms latency. Low orbit satellites, being almost 40 times closer have latencies closer to 10 ms, which is pretty good. The reclamation was addressed in the summary, which I'm guessing you stopped short of reading.
The company likes to spotlight its competition with the O3b, the Google-backed satellite project to improve Net access for the 3 billion people who live outside of wealthy, well-wired areas.
Sounds like more options and much needed competition on the way. If it's not tied to another service the way DSL, Cable, and Cell service is, it could heat up the ISP market. I do wonder if and how RF saturation might limit the market potential for this tech.
We need MPEG-LA specifically because it puts an end to bullshit like this.
We have MPEG-LA and it obviously doesn't put an end to bullshit like this. What we need is to abolish the software patents that got us here in the first place.
To be more specific, more software has been written for win32 than all other platforms combined. But, we're talking about tablets here. And for the kind with no keyboard or mouse, win32 apps do not run well, because their interface doesn't work. That should be clear after the failure of previous Windows tablets and the success of the iPad. So if we're talking about iPad competitors, win32 application compatibility it irrelevant.
As much as I agree that programmers tend to overestimate their importance -- a trait that pretty much every job category shares to one degree or another -- I think the idea is of negligible importance compared to the marketing.
Marketing is most important? I guess that depends on what you value. Maybe for maximizing profits. Consider what happens when a terrible movie gets marketed heavily. It still flops as soon as the first wave of duped people watch it and get the word out.
What's important is progress, and that comes from good ideas followed up with good implementations. And you don't have to be a magnate to see this.
Most everyone doesn't want a phone where they "have" to tweak it to get it to do what it is supposed to do. No being "interested" is different though. A geek (Slashdot target audience - NEWS FOR NERDS) will certainly be interested. I have a life outside of programming/computers, but I'm still addicted to it. I do it even when it does not make sense time or money wise, because I enjoy it. It's like any other hobby or passion. BTW, iOS and Android are too closed for me. I use an N900.
You described the issue with instantaneous capacity that has always been a problem for cellular communication, but that doesn't explain the 5GB limit. I'm sure most users would rather be connected all of the time, some or most of it being at less than the maximum data rate rather than to use their LTE service at full speed for a few days and then have to cease usage completely because they hit the 5 GB limit.
Don't just factor dose. Consider the intensity also. That is one of Bruce's points. As an analogy, consider getting hit by 1000 gallons of water from a garden hose vs 1000 gallons from a fire hose. Same dose, different intensity. Add to that the dose being delivered to the skin instead of being distributed throughout the body.
My experience has been similar to yours. I agree with you about the issues that exist, though I don't agree with your prescription to use only the basic features. ORM can drastically reduce code complexity and still perform well if you are willing to properly learn how to use the library and understand performance trade-offs. The main problem is that most people aren't willing to put in the time and effort (as with most everything in life).
Some tips.
When using ORM, you have do have to pay attention to what's happening underneath. It's a trade-off, but in the end your code is much more simple and portable. After spending time with an ORM, surprise, you learn how to use it better.
Salts protect against rainbow tables, not necessarily short passwords. In most situations, the salt needs to be known by both parties and is sent in the transmission so that the salt is not a secret. Don't count on the salt being a secret. You still need to choose a good password. Using a salt just means an attacker won't be able to look up the hash in a rainbow table.
Nokia has been supporting Maemo as an also run Windows mobile type smart phone OS for a long time, and having iPhone, Android, WebOS, and WP7 absolutely blow their offerings out of the water means that something had to change with them. I'm not sure why they just can't pull something compelling together, but its hurting the company until they work on getting something. I personally think that bringing in Qt was a bad decision which has at least in a small part hindered efforts to get product to market.
I agree with everything else but this. Have you used an N900? Maemo is the most capable of the mobile OS's and it's a solid progression from the previous versions. The interface is slick - four desktops with useful widgets, combined IM/SMS/SIP "conversations", nice view of multiple running apps and more. The reasons it's niche is because Nokia has not aimed Maemo at the general public, but instead has targeted a small geek market. In fact the N900 is marketed as a mobile computer, not a phone. I'll bet their next Maemo or Meego offering will be a smart phone.
Qt has long surpassed GTK and since Nokia owns the company they'd be nuts not to use it. From what I can tell they've done a fine job of transitioning developers.
Since you mentioned Python directly
Java's JVM does true multithreading.
So does Python. It uses POSIX threads.
Productive, predictable concurrency is possible in Java and not in many other languages
I don't buy that for second. I've written enough multi-threaded and multi-process applications in Python to know that it works well. That is, Python facilitates productive, predictable concurrency. I'll give you the GIL issue, which prevents maxing out multiple CPUs for CPU intensive multi-threaded tasks, but it's not an issue for threading IO (disk and network) bound tasks. And for processor heaving concurrent tasks, the multiprocessing module is well suited.
Java includes a lot of well-organized, stable libraries for doing everything from handling HTTP requests and crafting responses to doing cryptography. Its collections API has many data structures that just aren't present in other languages without looking to a third party.
Python has that too. In fact, its native list and dict types take care of most needs. Although there is a collections module too - no third party software needed. Cryptography has been blocked by the U.S.'s stupid export laws. Pycrypto is available for crypto needs.
Finally, the JVM makes naive code fast. One can write reasonably expressive, straightforward code and expect that the hotspot compiler will optimize it. It's a boon for getting maintainable, quality code out-the-door quickly.
I don't think this gives Java much advantage. Python is arguably more expressive and readable. Everyone here has their own experience they will draw on. Mine has been that although the JVM is much faster, the programs written in Python are at least fast enough, as fast, or sometimes even faster than the Java equivalent. I think this is because often times, much of the processing for Python apps is handled by modules written in C. Anyway, the issues I've run into haven't included apps running too slowly and the "expressive and readable" part are more important to me.
The argument isn't about the license, it's about patents. At any time, MS could step in and say that they own patents essential to the Mono implementation. That's why people are cautious about Mono and why most steer clear of it.
I think you're being too harsh. I looked at the script and it's very short and fairly easy to read. How can you complain about that? I couldn't get to the website to download the Windows tool, but I'm going to guess it's a compiled exe (could be wrong), which means it's not easy for the user to edit. By contrast, the user can easily tailor the Python script to fit their needs. In addition, the script also serves as format documentation. He clearly commented sections such as "daily record", "error record" and "1 second record".