I've advocated didgital postage for several years on precisely the same grounds. Like here: http://slashdot.org/comments.pl?sid=26155&c id=2833 606
People reject it out of hand because: 1) they think it would have to be centralized 2) they think they would have to pay more
Both notions are dead wrong. Imagine the following:
1) Every email client mints their own postage 2) An email client always rejects email without postage 3) It includes plenty of postage in the rejection email
At minimum, this would force spammers to provide valid return addresses. Of course it would be cumbersome until well integrated into the popular email clients.
Once spammers start needing to read rejection emails, they have lost the war. Digital postage can be made almost arbitrarily expensive to obtain in CPU cycles without significantly hampering actual users. Actual users can usually spend an hour of CPU time generating a stamp to contact someone for the first time. Spammers can't.
I may have gotten the deatils wrong, but I'm firmly convinced that digital postage is the only way to end spam.
While the 2600 didn't have much RAM, the cartridges contained all the ROM. A cartridge was/is free to supply as much RAM and ROM as it wanted. Most just supplied ROM. 2K may have been a standard size, but it wasn't a hard limit by any means. In many ways, a 2600 was just a 400/800 without a keyboard and very little RAM.
The RAM (256 bytes IIRC) was the real limit, since adding any RAM to a cartridge drastically increased the cost of manufacturing it. With only 256 bytes (no video memory), you have to do completely insane things like chase the electron gun across the screen to draw things.
A while back, I worked for a company developing a web-based application that had to make phone calls. My preferred solution would have been to handle the calls completely in software. That way our scalability problems would be limited to CPU and bandwidth.
After much searching for a suitable vendor, we finally went with a hardware (Dialogic) based solution. Has Net2Phone ever considered supplying software for the JSP/J2EE world? I haven't been keeping up, so perhaps they do, now. If so, does anybody have a link for it?
I've been looking for this type of device too. If anyone who has actually done this could post a detailed HOWTO, I would really appreciate it.
I already have a DSB-R100, and tried using a Win2K installation for this. I gave up and uninstalled all the related software, because the driver made my machine too flaky. I guess it's time to try again on a Linux machine.
Here's some dedicated hardware that could be used for a radio TiVo.
I think you actually mean an "open-standards zealot". J2ME is a very thoroughly documented open standard. J2ME implementations are free to be closed-source and I believe most of them are.
I freely admit to being both an open source and open standards zealot. With that said, it is very difficult to argue with what I took to be his main point. Namely, if you intend to do some coding for personal use or enjoyment, you will probably find J2ME much more suitable than BREW. This is especially true if you already like Java.
Damion, both you and WallsRSolid are quite easily astonished
If all is as you claim, you should step back, do some more homework concerning pen computing, and look at this story more objectively. Microsoft has been a long-time player in pen computing, but never an innovator. Bringing an existing technology into the Microsoft-only world doesn't count as innovation.
If the submission had consisted of technical specifications and details, they would have been discussed. Geeks eat details. Instead, the submission consisted of vague adjectives. That makes discussing the vague adjectives on-topic.
Microsoft makes some quality products. Until they decide that none of their products need to be marketed by illegally abusing their monopoly, their marketing hype will be subject to more scrutiny than their competetors.
Re:As Shakespeare said (more or less)
on
Linux Kernel 3.0?
·
· Score: 1
I'm sure this line has been used countless times before, but the one I remeber is from the old Remmington Steele TV series. It went something like:
Ms. Holt: So what is your name anyway? Remmington Steele: A rose by any other name... Murphy: Still has thorns.
My sister will soon be a history teacher in rural Illinois. She is a gamer, and would gladly assign the right game as homework. There are equal access issues to consider, however. If the school doesn't have a nice big computer lab, you've just assigned homework that only the relatively rich kids can do.
I've used VNC, and I find it pokey when Windows is serving. It is quite fast, however, when Linux is serving. TightVNC is faster still. And then there is X, which trumps everything in terms of speed, but doesn't serve from Windows AFAIK.
I would have no problem checking email, editing documents etc... using any of these when Linux is serving.
The Drake equation, SETI, and the Fermi Paradox
on
Rare Earth
·
· Score: 1
Let's just assume that a planet just like Earth[TM] is the only way to get intelligent life. Add all of the extra pessimistic factors described in the article to the Drake equation. Put in reasonable values for everything. If you get an answer greater than one the Fermi Paradox means that finding intelligent life (or it finding you) is still likely, if you manage to keep a civilization around long enough.
Does anyone else have an opinion on the suitability of Java in medium (Limewire) to large (thinkFree's product) desktop applications?
Yes, Java is suitable for large desktop applications. I write them for a living, so I am somewhat knowledgeable, but quite biased. Although, what do you mean large? jEdit? Forte?
There are lots of ways to produce Java desktop apps, but since the original subject is ThinkFree, I'm only going to address Swing based apps.
Suitable in what way? Good coding habits, a roadmap for what the app should do, a complete understanding of the Java language, and a good knowledge of whatever Java APIs you will work with, are all very helpful if you want to produce a maintainable and reliable app. If you satisfy all of these requirements, you should be able to produce a desktop app that does what you want quickly.
I firmly believe "Make it work, then make it fast". Proper use of interfaces in Java is the key to turning a working implementation into a fast implementation.
Other than a moderate start-up cost, if a Swing based application is slow, that means that fixing bugs and adding more features has been more important to the developers than making the application faster/more responsive. Swing apps are very easy to develop, so Java is very suitable in that sense.
A very usable profiling option is available under java in all recent (1.2+?) JDKs. If a Swing app isn't fast, it hasn't gone through any iterations with a developer interested in making it fast.
Swing is single-threaded, and sometimes multilple threads are essential for responsiveness. I don't know of a language with better threading support than Java, but a multi-threaded program is generally harder to write and debug than a single-threaded one.
So, if I'm reading this right, it will run Windows CE, and allow you to do remote desktop stuff with a Windows XP machine via Windows Terminal Server. That sounds really nifty, except I don't want to run Windows XP, ever.
Perhaps it could also net-boot and run Linux Terminal Server, instead. Are there any good X Servers for Windows CE? Any GPL'd? I think there is a GPL'd Java one that might run on Windows CE.
I know that VNC runs on Windows CE. While VNC is very slow when connecting to a Windows machine, it is quite fast connecting to a Linux machine. From what I understand, it isn't as fast as Cygwin/Xfree,but the install is sooooooooooo much easier.
At work we produce desktop and workstation applications for a clients. We use Java quite heavily, but since most of our stuff is written for a particular client, you would only ever encounter it, if you were a user it was installed for. As a member of the general public, you will never know about it.
While there is a certain potential for J2ME generic applications, I think it works pretty much the same way. J2ME clients will be written largely for internal corporate applications. Since many corporate web based applications are based on JSP, Servlets, or even J2EE, using Java at both ends has lots of advantages.
At a previous employer, we were doing just that. It would have made things drastically easier, if we could have written for J2ME cell phones, instead of the various cell-phone "micro-browsers" we had to write for.
The 9210 runs PersonalJava on Symbian. A future version will run J2ME on Symbian. That would be my guess about the other phones, as well. Then again, I thought the Nokia MediaTerminal just ran Linux.
Currently, you can't download the developer kit for 9210 from Nokia's site. You need to sign up and give them a postal address. They will send you a free CD. I'm personally very interested in the 9210 because of its JTAPI implementation. I assume that the other models lack that. Are there any other Java developers out there who have written code for the 9210 and would like to share tips or resources?
Unsolicited bulk email is used with such frequency because it is so incredibly cheap. This convinces those who use it, that it has a positive return on investment. In order to reduce the amount of spam, it is necessary to increase the cost of sending it. Digital postage is the only way to reduce spam.
This would be analogous to the stamps used on snail mail, now. If nobody else steps up to the plate, some corporations will try to do this for a profit, or national governments will try to do it for control. The better solution, however, is some sort standards-based decentralized digital postage, where everyone can issue their own estamps. It is then up to each individual to decide, how much a spammer has to pay to get to their inbox.
Of course to be widely adopted, this has to be well integrated into email clients. It also has to be completely painless to insure that your friends always have enough of your stamps on-hand.
Once in place, the benefits include:
- less spam
- no need for email size limits, because there would be an obvious mechanism to allow billing for arbitrarily large emails
- automatic payment method for email based customer support
I don't know how well this translates into Perl, but if the project is in Java, the steps are pretty straightforward.
1. Determine a clean architecture for how you would have solved the problem, given the benefit of hindsight.
2. Create new interfaces based on your new architecture.
3. Code facades to make your old code implement the new design.
4. One by one, re-implement your new interfaces until the new implementation has solved all of the problems that led you to re-implement in the fist place.
Of course, during development and maintenance, you should be doing all of this stuff everyday, anyway. Reimplementing everything just means the team has agreed on a global change in design, as opposed to the local design changes you don't need any co-operation to achieve.
If you follow this approach, you always can always have working code at the end of the day.
If we had some sort of centralized "person information system" that could be used by governments, corporations, and private citizens--all on equal footing, then we would actually reduce the risk of this sort of thing happening. Granted, that would be putting all of our eggs in one basket. However, we could make one extremely well designed, extensively peer-reviewed basket. The current system is for everybody to build their own baskets. Nobody has many eggs, but lots of eggs get cracked, dropped, and stolen because the average basket is so incredibly shitty.
If we do nothing, M$ will force a poorly designed basket with lots of eggs, that they own alone. Don't worry. It will be free--for a while.
Slashdot Mirror
I've advocated didgital postage for several years on precisely the same grounds. Like here:c id=2833 606
http://slashdot.org/comments.pl?sid=26155&
People reject it out of hand because:
1) they think it would have to be centralized
2) they think they would have to pay more
Both notions are dead wrong. Imagine the following:
1) Every email client mints their own postage
2) An email client always rejects email without postage
3) It includes plenty of postage in the rejection email
At minimum, this would force spammers to provide valid return addresses. Of course it would be cumbersome until well integrated into the popular email clients.
Once spammers start needing to read rejection emails, they have lost the war. Digital postage can be made almost arbitrarily expensive to obtain in CPU cycles without significantly hampering actual users. Actual users can usually spend an hour of CPU time generating a stamp to contact someone for the first time. Spammers can't.
I may have gotten the deatils wrong, but I'm firmly convinced that digital postage is the only way to end spam.
While the 2600 didn't have much RAM, the cartridges contained all the ROM. A cartridge was/is free to supply as much RAM and ROM as it wanted. Most just supplied ROM. 2K may have been a standard size, but it wasn't a hard limit by any means. In many ways, a 2600 was just a 400/800 without a keyboard and very little RAM.
The RAM (256 bytes IIRC) was the real limit, since adding any RAM to a cartridge drastically increased the cost of manufacturing it. With only 256 bytes (no video memory), you have to do completely insane things like chase the electron gun across the screen to draw things.
What about a Java-based one?
A while back, I worked for a company developing a web-based application that had to make phone calls. My preferred solution would have been to handle the calls completely in software. That way our scalability problems would be limited to CPU and bandwidth.
After much searching for a suitable vendor, we finally went with a hardware (Dialogic) based solution. Has Net2Phone ever considered supplying software for the JSP/J2EE world? I haven't been keeping up, so perhaps they do, now. If so, does anybody have a link for it?
Needlessly exposing a database to the Internet is a security policy so bad that not even Microsoft would recommend it.
Anyone know of any projects to compile JVM bytecode from other languages?
I already have a DSB-R100, and tried using a Win2K installation for this. I gave up and uninstalled all the related software, because the driver made my machine too flaky. I guess it's time to try again on a Linux machine.
Here's some dedicated hardware that could be used for a radio TiVo.
I freely admit to being both an open source and open standards zealot. With that said, it is very difficult to argue with what I took to be his main point. Namely, if you intend to do some coding for personal use or enjoyment, you will probably find J2ME much more suitable than BREW. This is especially true if you already like Java.
If all is as you claim, you should step back, do some more homework concerning pen computing, and look at this story more objectively. Microsoft has been a long-time player in pen computing, but never an innovator. Bringing an existing technology into the Microsoft-only world doesn't count as innovation.
If the submission had consisted of technical specifications and details, they would have been discussed. Geeks eat details. Instead, the submission consisted of vague adjectives. That makes discussing the vague adjectives on-topic.
Microsoft makes some quality products. Until they decide that none of their products need to be marketed by illegally abusing their monopoly, their marketing hype will be subject to more scrutiny than their competetors.
I'm sure this line has been used countless times before, but the one I remeber is from the old Remmington Steele TV series. It went something like:
Ms. Holt: So what is your name anyway?
Remmington Steele: A rose by any other name...
Murphy: Still has thorns.
Medieval: Total War
My sister will soon be a history teacher in rural Illinois. She is a gamer, and would gladly assign the right game as homework. There are equal access issues to consider, however. If the school doesn't have a nice big computer lab, you've just assigned homework that only the relatively rich kids can do.
but I suppose other people want to profile more than just Java. Bother.
Could you provide a URL, or at least a product name for that?
I've used VNC, and I find it pokey when Windows is serving. It is quite fast, however, when Linux is serving. TightVNC is faster still. And then there is X, which trumps everything in terms of speed, but doesn't serve from Windows AFAIK.
I would have no problem checking email, editing documents etc... using any of these when Linux is serving.
Let's just assume that a planet just like Earth[TM] is the only way to get intelligent life.
Add all of the extra pessimistic factors described in the article to the Drake equation. Put in reasonable values for everything. If you get an answer greater than one the Fermi Paradox means that finding intelligent life (or it finding you) is still likely, if you manage to keep a civilization around long enough.
Yes, Java is suitable for large desktop applications. I write them for a living, so I am somewhat knowledgeable, but quite biased. Although, what do you mean large? jEdit? Forte?
There are lots of ways to produce Java desktop apps, but since the original subject is ThinkFree, I'm only going to address Swing based apps.
Suitable in what way? Good coding habits, a roadmap for what the app should do, a complete understanding of the Java language, and a good knowledge of whatever Java APIs you will work with, are all very helpful if you want to produce a maintainable and reliable app. If you satisfy all of these requirements, you should be able to produce a desktop app that does what you want quickly.
I firmly believe "Make it work, then make it fast". Proper use of interfaces in Java is the key to turning a working implementation into a fast implementation.
Other than a moderate start-up cost, if a Swing based application is slow, that means that fixing bugs and adding more features has been more important to the developers than making the application faster/more responsive. Swing apps are very easy to develop, so Java is very suitable in that sense.
A very usable profiling option is available under java in all recent (1.2+?) JDKs. If a Swing app isn't fast, it hasn't gone through any iterations with a developer interested in making it fast.
Swing is single-threaded, and sometimes multilple threads are essential for responsiveness. I don't know of a language with better threading support than Java, but a multi-threaded program is generally harder to write and debug than a single-threaded one.
So, if I'm reading this right, it will run Windows CE, and allow you to do remote desktop stuff with a Windows XP machine via Windows Terminal Server. That sounds really nifty, except I don't want to run Windows XP, ever. ,but the install is sooooooooooo much easier.
Perhaps it could also net-boot and run Linux Terminal Server, instead. Are there any good X Servers for Windows CE? Any GPL'd? I think there is a GPL'd Java one that might run on Windows CE.
I know that VNC runs on Windows CE. While VNC is very slow when connecting to a Windows machine, it is quite fast connecting to a Linux machine. From what I understand, it isn't as fast as Cygwin/Xfree
At work we produce desktop and workstation applications for a clients. We use Java quite heavily, but since most of our stuff is written for a particular client, you would only ever encounter it, if you were a user it was installed for. As a member of the general public, you will never know about it.
While there is a certain potential for J2ME generic applications, I think it works pretty much the same way. J2ME clients will be written largely for internal corporate applications. Since many corporate web based applications are based on JSP, Servlets, or even J2EE, using Java at both ends has lots of advantages.
At a previous employer, we were doing just that. It would have made things drastically easier, if we could have written for J2ME cell phones, instead of the various cell-phone "micro-browsers" we had to write for.
The 9210 runs PersonalJava on Symbian. A future version will run J2ME on Symbian. That would be my guess about the other phones, as well.
Then again, I thought the Nokia MediaTerminal just ran Linux.
Currently, you can't download the developer kit for 9210 from Nokia's site. You need to sign up and give them a postal address. They will send you a free CD.
I'm personally very interested in the 9210 because of its JTAPI implementation. I assume that the other models lack that.
Are there any other Java developers out there who have written code for the 9210 and would like to share tips or resources?
$80 seems pretty optimistic for a useful machine.
You can get a IBM ThinkPad Transnote for $800, which seems like a steal to me.
Do you really need a laptop?
Apple Newton Message Pad 2100's and Sonic Blue Revo's seem to be going for $100-150 on eBay.
- What is good hardware?
- Does the wearables mailing list have a public archive?
Any info is greatly appreciated. ThanksUnsolicited bulk email is used with such frequency because it is so incredibly cheap. This convinces those who use it, that it has a positive return on investment. In order to reduce the amount of spam, it is necessary to increase the cost of sending it. Digital postage is the only way to reduce spam.
This would be analogous to the stamps used on snail mail, now. If nobody else steps up to the plate, some corporations will try to do this for a profit, or national governments will try to do it for control. The better solution, however, is some sort standards-based decentralized digital postage, where everyone can issue their own estamps. It is then up to each individual to decide, how much a spammer has to pay to get to their inbox.
Of course to be widely adopted, this has to be well integrated into email clients. It also has to be completely painless to insure that your friends always have enough of your stamps on-hand.
Once in place, the benefits include:
- less spam
- no need for email size limits, because there would be an obvious mechanism to allow billing for arbitrarily large emails
- automatic payment method for email based customer support
I don't know how well this translates into Perl, but if the project is in Java, the steps are pretty straightforward.
1. Determine a clean architecture for how you would have solved the problem, given the benefit of hindsight.
2. Create new interfaces based on your new architecture.
3. Code facades to make your old code implement the new design.
4. One by one, re-implement your new interfaces until the new implementation has solved all of the problems that led you to re-implement in the fist place.
Of course, during development and maintenance, you should be doing all of this stuff everyday, anyway. Reimplementing everything just means the team has agreed on a global change in design, as opposed to the local design changes you don't need any co-operation to achieve.
If you follow this approach, you always can always have working code at the end of the day.
The GPL is hardly incompatable with profit.
Prentice Hall would have sold a ton of these if they had GPL'd Minix.
If we had some sort of centralized "person information system" that could be used by governments, corporations, and private citizens--all on equal footing, then we would actually reduce the risk of this sort of thing happening. Granted, that would be putting all of our eggs in one basket. However, we could make one extremely well designed, extensively peer-reviewed basket. The current system is for everybody to build their own baskets. Nobody has many eggs, but lots of eggs get cracked, dropped, and stolen because the average basket is so incredibly shitty.
If we do nothing, M$ will force a poorly designed basket with lots of eggs, that they own alone. Don't worry. It will be free--for a while.