Hear, hear! And Sun even have libraries like JDNC and JDIC which are making desktop integration and deployment a lot more friendly. It cannot be said that Sun aren't attempting to improve their desktop integration, particularly since that was one of the major focuses of the 5.0 release!
Also, KDevelop has happily embedded KVim for ages now.
Is that enough?
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
I'm surprised the poster above didn't mention the best IDE in existence, IntelliJ IDEA. IDEA does everything you describe and a lot more, and every time I use Eclipse I come across another missing feature which makes me miss IDEA.
True enough for the SP. I take it to work and back for the public transport... and it's in my hands the entire time between the two places. Ever seen someone swipe a ticket while still playing his GameBoy? That would have been me.;-/
So what you're saying is, without the Power Pad, there would be a lot less people looking like retards at the video arcade. I don't know if that's good or bad!
When you get the results back, how do you navigate to the web site? Wouldn't it have made more sense to use Google via WAP in the first place, if you're inevitably going to end up there later?
A HTC file is a "Hypertext Component", which is what IE uses to effectively make arbitrary applications using HTML, XML or whatever. Amongst more nifty uses like this, I have seen it used to automatically colour code in
blocks, and make things move around the screen.:-)
Certificates tied to real people would certainly be an improvement from the current S/MIME system, where they are all tied to faceless corporations who I don't even trust.
I like OpenPGP simply because the keys are tied to real people. Real people who I have to meet to get the signatures. Real people with names, unlike the faceless corporations who deal out things like SSL certificates. When was the last time anyone trusted a corporation over their friends?
But yeah. We can implement both, it will just take 10 times longer to implement the S/MIME E2E spec as it does to implement the OpenPGP one.
I'm seriously curious about that. Windows has a number of "phone home" features which can't be turned off (but can be blocked through other means, I suppose)...
What would be the fine for installing spyware in every Windows XP system in the entire country?;-)
Not really, because we can still send the same pictures via 802.11b, just that it will have to be from another Nintendo DS. Until someone figures out the protocol (which the Warp Pipe team are apparently working with.):-)
It actually is WiFi, as in 802.11b, just powered down. Also, they did say that the networking was proprietary, so who knows if it will be IP running over that 802.11b connection... it might not be.
In a way, I would have preferred Bluetooth. You can still get 25 metre range off it, if it's needed. It would be able to chat with phones. And most importantly, I would be able to bluejack little kids with disturbing pictures.:-/
Gabber does the OpenPGP JEP too, incidentally. I think they were actually the first ones to implement it. A few less popular clients do also, and I have a bot which can converse in it as a result of work on my failed JabberStudio project.:-)
I suppose that in order to maintain my project, I now have to do a whole lot of research into S/MIME. Otherwise whatever crypto I use won't be "compliant."
Honestly though, the difference between OpenPGP and S/MIME should just be the formats. Couldn't the same message encrypted with the same key be formatted in both OpenPGP and S/MIME formats? Perhaps the key problem doesn't have to be a problem at all.:-/
The certificate side of things is exactly what hurts, as a user. Either you pay bucks, or you use CAcert. But either way, the steps are far, far more complicated than "gpg --gen-key".
A good summary of the new E2E spec would be "wrap the XML which made things so simple into another format which will require you to write a new parser, then encrypt that, wrap it in S/MIME, and put it back into the XML."
Maybe if 99.9% of the people were running servers, I would buy the difficulty angle. But most users are running clients, and clients don't see any problem with the frame rubbish you keep going on about. Implementing a server is going to be hard regardless... the argument on scalability is hardly going to lie somewhere in the realm of XML parsing, since XML parsing is trivial if you re-use someone else's code.
Once again... who has to worry about "writing correct software", if the software is already written? Only the person who wrote the library you use.
Neither the CRLF parser, nor the XML parser have to be written by me, since they have both already been done and I can re-use other people's existing parsers. Why write a new one? Boredom?
Slashdot Mirror
I think everyone here knows about PearPC already, since it's been covered a few times on Slashdot already.
This is what I'm saying:
Poster 1: "you can already do Mac on Linux for free.... Mac On Linux"
Poster 2: "but that's linux/ppc not linux/X86"
You: "No it's not."
But the original comment said Mac on Linux, not PearPC.
Hear, hear! And Sun even have libraries like JDNC and JDIC which are making desktop integration and deployment a lot more friendly. It cannot be said that Sun aren't attempting to improve their desktop integration, particularly since that was one of the major focuses of the 5.0 release!
There is a VIM Emulator Plugin for IntelliJ IDEA.
There is also a Vi Plugin for Eclipse.
Also, KDevelop has happily embedded KVim for ages now.
Is that enough?
I'm surprised the poster above didn't mention the best IDE in existence, IntelliJ IDEA. IDEA does everything you describe and a lot more, and every time I use Eclipse I come across another missing feature which makes me miss IDEA.
So exactly like add*Listener and remove*Listener methods, just with different syntax.
(1) So you're saying that DDR players are at Olympic standards? I haven't heard of any cases where a DDR addict has entered an Olympic sport and won.
(2) "Retard" is a colloquial term which doesn't necessarily apply to "special" people. It applies to people who are, well, retards.
True enough for the SP. I take it to work and back for the public transport... and it's in my hands the entire time between the two places. Ever seen someone swipe a ticket while still playing his GameBoy? That would have been me. ;-/
So what you're saying is, without the Power Pad, there would be a lot less people looking like retards at the video arcade. I don't know if that's good or bad!
When you get the results back, how do you navigate to the web site? Wouldn't it have made more sense to use Google via WAP in the first place, if you're inevitably going to end up there later?
It sounds like they already are the king of spam, sending out all this unsolicited email!
Almost all FAQs seem to lack the most important question: "Where is the FAQ?"
You'd be surprised how many people ask that question, even if you put it directly there in the FAQ, they still keep asking it. Crazy stuff.
Also to save people the trouble, if you've installed Windows XP SP2, this won't run.
Certificates tied to real people would certainly be an improvement from the current S/MIME system, where they are all tied to faceless corporations who I don't even trust.
I like OpenPGP simply because the keys are tied to real people. Real people who I have to meet to get the signatures. Real people with names, unlike the faceless corporations who deal out things like SSL certificates. When was the last time anyone trusted a corporation over their friends?
But yeah. We can implement both, it will just take 10 times longer to implement the S/MIME E2E spec as it does to implement the OpenPGP one.
I'm seriously curious about that. Windows has a number of "phone home" features which can't be turned off (but can be blocked through other means, I suppose)...
What would be the fine for installing spyware in every Windows XP system in the entire country? ;-)
Not really, because we can still send the same pictures via 802.11b, just that it will have to be from another Nintendo DS. Until someone figures out the protocol (which the Warp Pipe team are apparently working with.) :-)
It actually is WiFi, as in 802.11b, just powered down. Also, they did say that the networking was proprietary, so who knows if it will be IP running over that 802.11b connection... it might not be.
In a way, I would have preferred Bluetooth. You can still get 25 metre range off it, if it's needed. It would be able to chat with phones. And most importantly, I would be able to bluejack little kids with disturbing pictures. :-/
If that were valid, it would need to be "Zauri". "us" -> "i".
Oh, yeah... I forgot to mention.
Gabber does the OpenPGP JEP too, incidentally. I think they were actually the first ones to implement it. A few less popular clients do also, and I have a bot which can converse in it as a result of work on my failed JabberStudio project. :-)
I suppose that in order to maintain my project, I now have to do a whole lot of research into S/MIME. Otherwise whatever crypto I use won't be "compliant."
Honestly though, the difference between OpenPGP and S/MIME should just be the formats. Couldn't the same message encrypted with the same key be formatted in both OpenPGP and S/MIME formats? Perhaps the key problem doesn't have to be a problem at all. :-/
The certificate side of things is exactly what hurts, as a user. Either you pay bucks, or you use CAcert. But either way, the steps are far, far more complicated than "gpg --gen-key".
Also, to illustrate what hurts as a developer, compare the current OpenPGP protocol to the new End to End spec.
A good summary of the new E2E spec would be "wrap the XML which made things so simple into another format which will require you to write a new parser, then encrypt that, wrap it in S/MIME, and put it back into the XML."
That's basically what I just said, isn't it?
"Nah. I'm just a clueless user."
Maybe if 99.9% of the people were running servers, I would buy the difficulty angle. But most users are running clients, and clients don't see any problem with the frame rubbish you keep going on about. Implementing a server is going to be hard regardless... the argument on scalability is hardly going to lie somewhere in the realm of XML parsing, since XML parsing is trivial if you re-use someone else's code.
Once again... who has to worry about "writing correct software", if the software is already written? Only the person who wrote the library you use.
Neither the CRLF parser, nor the XML parser have to be written by me, since they have both already been done and I can re-use other people's existing parsers. Why write a new one? Boredom?