One thing I noticed in the DASD photo: It's totally inaccurate. -Nobody- has ever had those old cabinets with their doors shut. They were always hanging open (if they were even attached), with rats nests of cables within and without.
A third possibility is that it is for a faster sync with the host. If you maintain hash digests on the ipod and the host, then you can test for equality by just comparing the hashes. If they are identical, then there is no need to sync. You can skip comparing everything else bit-by-bit.
The original SCO, the Santa Cruz Operation, made some good software. We had several servers running it many years ago, along with a few with re-branded "Dell Unix." It's a shame that the original company will be forgotten because of this current abomination.
The general handshaking mechanism itself is not in danger. It is the prime factor-based RSA algorithm. There might be other key algorithms in danger as well, but this doesn't reflect on the PK framework.
During Hurricane Rita, there seemed to be 4 things that were important to get to the affected people: water, electricity, ice, and chainsaws (yes, chainsaws). If there were some simple, cheap source of electricity, (like the OLPC?) it would be fantastic.
I would like to say that I -never- looked at anyone's data, all of the times I maintained accounts for people. But I did only once, when I suspected that someone had shared their password with a non-employee and that person was logging into the company (which turned out to be correct). So I guess I can justify my snooping by -their- breach of trust. But I still wish that I had not marred my perfect record, although nobody cares about it but me.
Dr_Barnowl is apparently leaving his scientific method behind when he makes assumptions about whether these things are viable. The "proof is in the pudding," as they say. The final judgment of this cell-mesh is: does it work?
I thought that this was going to be the thing that saved wireless on Linux. Instead of needing kernel support, along with deep knowledge and source code in order to build a loadable module, all you need to know is the wlan_ng API, and compile your driver for that. Much simpler and cleaner. And you would then need only the same API for all of your discovery tools, GUIs, etc. But except for a couple of handheld Linuxes, I haven't seen it deployed much. Anything would be easier than the cranky PCMCIA and hotplug frameworks.
I know it's a slow Sunday, but please, enough of the sales pitch.
I for one am hoping that US nuclear operators will begin investing in newer technology, like the pebble-bed reactor. This one is an old idea, but recently implemented. It is inherently safer than rods & dampers, and is unable to go into meltdown. And the reactors can be smaller and can be located closer to the power-users for efficiency and economy.
Changing the system from first to invent to first to file will only help incumbents who already have patent attorneys on staff. The original intention of patents, to give the innovator a head start in business, will be lost.
Not fair. One is fine, but six are just begging someone to do the work for you. ^^
But have you considered particle modeling? Fill your experiment space with a large number of points representing your medium, and model each one only in how it reacts to its environment and neighbors. Then let it run, and watch the results. It is not determinstic, but you can often get a statistically close simulation of the real thing.
The one thing that is left out of the client, Multi-User Chat Groups, should really be added to the client. I realize that Google probably doesn't want the legal hassles of managing chat "rooms." But they don't need to put them on their server, just give the client the ability to use MUC on -other- conference servers.
Ever since the record industry began casting aside the talented musicians in favor of "singer-dancers," they have had total disdain for the public. They have known for years that they can take the most untalented act, wrap it up in a pretty package and saturation-market it, and the mongrel public will stupidly buy it. Ask yourself: "what instruments do they play?" and "do they write their own music?" Then go to your CD shelf and start throwing out the embarrassing evidence before anyone sees it. Look for anything that is eyecandy + microphone.
Are they now suffering from the cruelties of the market? No. They are finally paying for their sins.
Just the fact that you are chatting happily on Slashdot indicates that you have Internet access, and you will likely not be a customer of any government-subsidized WiFi. The people who are NOT speaking here are the potential beneficiaries. Think more altruistically. Just because YOU don't need it, doesn't mean that other people don't.
That is like saying, "Why donate food and clothing to the homeless? I have all I need."
People should probably search for old examples of email "servers," such as the ones that respond to commands like, "get myfile.zip." These go way back to even before people commonly had Internet connections, when they had dialup UUCP and Compuserve and such. There was even a system called "M0" , that had a grammar for interpreted email scripts.
Oh, and don't forget LISTSERV and Majordomo!
Using smarts to guess the information and context of a given message does definitely have ancestors in software that would scan USENET postings for useful stuff. Remember that originally USENET was more like email and predated the "news:" protocol.
Mixing AWT and Swing widgets has been fixed in current Java 7 builds. That sounds wonderful. I didn't know that this had happened. Good news! So there is no longer a split between the NNNN and JNNNN widget classes?
Meaning that you can read JList info from the java.util.List, or write to a java.util.List and have the changes appear in the JList on the next repaint. This is another much-anticipated feature that will be greatly appreciated. Good to see that the new development efforts are paying off.
You're right! After years of writing documents, I try to avoid stuff like that, along with "should" and "must," as if it's implying something official. I nee^H^H^H will try to be more careful.
Of course. That's why I said "keep maintaining 1.x." ^^ Yes, I know that there is a huge installed base of 1.x. Keep 1.x runtimes in maintenance mode in perpetuity to support them, but allow people to benefit from years of lessons learned about what is needed in the runtime.
It's good to see that there is at least one project aimed at cleaning up old legacy code. The thing needed most by Java, IMHO, is not more features, but a thorough cleanup of the runtime classlib. The packages and classes need to be rearranged logically, renamed, made to have consistent API's and naming patterns. Redundancies need to be removed (like 3 different RPC schemes and APIs), and deprecations finally need to be pruned. Collections- and non-collections-containers need to be merged, and AWT and Swing need to be reconciled. There needs to be a declarative GUI design grammar. Maybe JavaFX's grammar could be borrowed for that. And the long-promised merging of Swing and Collections needs to happen, too. (Like a popup list could be accessed as a java.util.List)
I have thought for years that there needs to be a "JDK 2.0" series started which would be a clean break from the 1.x series. Keep maintaining the 1.x series, but make a fresh start.
First the spec development process, then the time-to-market, and now the market shakeup are all making certain that both standards will be obsolete by the time that one of them has one their little war.
Neither one is anywhere near cutting edge any more, as technology marches on.
> I would think delivery vehicles directly support the community.
Exactly what I meant. The vehicles necessary to run the place, not the extraneous traffic that people bring in from other places. I was in agreement with his viewpoint, but I guess he didn't notice.
Slashdot Mirror
Too bad they got out of the game. Just when it was starting to become fun.
Before that... well, it was probably the C-64.
And RACF for security.
One thing I noticed in the DASD photo: It's totally inaccurate. -Nobody- has ever had those old cabinets with their doors shut. They were always hanging open (if they were even attached), with rats nests of cables within and without.
A third possibility is that it is for a faster sync with the host. If you maintain hash digests on the ipod and the host, then you can test for equality by just comparing the hashes. If they are identical, then there is no need to sync. You can skip comparing everything else bit-by-bit.
The original SCO, the Santa Cruz Operation, made some good software. We had several servers running it many years ago, along with a few with re-branded "Dell Unix." It's a shame that the original company will be forgotten because of this current abomination.
That was a very entertaining read. I love it when strong personalities squabble, and egos collide. Open Source is Fun!
The general handshaking mechanism itself is not in danger. It is the prime factor-based RSA algorithm. There might be other key algorithms in danger as well, but this doesn't reflect on the PK framework.
During Hurricane Rita, there seemed to be 4 things that were important to get to the affected people: water, electricity, ice, and chainsaws (yes, chainsaws). If there were some simple, cheap source of electricity, (like the OLPC?) it would be fantastic.
I would like to say that I -never- looked at anyone's data, all of the times I maintained accounts for people. But I did only once, when I suspected that someone had shared their password with a non-employee and that person was logging into the company (which turned out to be correct). So I guess I can justify my snooping by -their- breach of trust. But I still wish that I had not marred my perfect record, although nobody cares about it but me.
Dr_Barnowl is apparently leaving his scientific method behind when he makes assumptions about whether these things are viable. The "proof is in the pudding," as they say. The final judgment of this cell-mesh is: does it work?
I thought that this was going to be the thing that saved wireless on Linux. Instead of needing kernel support, along with deep knowledge and source code in order to build a loadable module, all you need to know is the wlan_ng API, and compile your driver for that. Much simpler and cleaner. And you would then need only the same API for all of your discovery tools, GUIs, etc. But except for a couple of handheld Linuxes, I haven't seen it deployed much. Anything would be easier than the cranky PCMCIA and hotplug frameworks.
I know it's a slow Sunday, but please, enough of the sales pitch.
I for one am hoping that US nuclear operators will begin investing in newer technology, like the pebble-bed reactor. This one is an old idea, but recently implemented. It is inherently safer than rods & dampers, and is unable to go into meltdown. And the reactors can be smaller and can be located closer to the power-users for efficiency and economy.
Changing the system from first to invent to first to file will only help incumbents who already have patent attorneys on staff. The original intention of patents, to give the innovator a head start in business, will be lost.
Not fair. One is fine, but six are just begging someone to do the work for you. ^^
But have you considered particle modeling? Fill your experiment space with a large number of points representing your medium, and model each one only in how it reacts to its environment and neighbors. Then let it run, and watch the results. It is not determinstic, but you can often get a statistically close simulation of the real thing.
The one thing that is left out of the client, Multi-User Chat Groups, should really be added to the client. I realize that Google probably doesn't want the legal hassles of managing chat "rooms." But they don't need to put them on their server, just give the client the ability to use MUC on -other- conference servers.
Ever since the record industry began casting aside the talented musicians in favor of "singer-dancers," they have had total disdain for the public. They have known for years that they can take the most untalented act, wrap it up in a pretty package and saturation-market it, and the mongrel public will stupidly buy it. Ask yourself: "what instruments do they play?" and "do they write their own music?" Then go to your CD shelf and start throwing out the embarrassing evidence before anyone sees it. Look for anything that is eyecandy + microphone.
Are they now suffering from the cruelties of the market? No. They are finally paying for their sins.
And how long did he think he could get away with it?
Just kidding. Bryce is a fine fellow, and is also the excellent boss of the Inkscape project.
Just the fact that you are chatting happily on Slashdot indicates that you have Internet access, and you will likely not be a customer of any government-subsidized WiFi. The people who are NOT speaking here are the potential beneficiaries. Think more altruistically. Just because YOU don't need it, doesn't mean that other people don't.
That is like saying, "Why donate food and clothing to the homeless? I have all I need."
Here is the news today. I know the link is in the blog, but it's far down the page and people might miss it:
. html
http://www.chron.com/disp/story.mpl/front/5092403
People should probably search for old examples of email "servers," such as the ones that respond to commands like, "get myfile.zip." These go way back to even before people commonly had Internet connections, when they had dialup UUCP and Compuserve and such. There was even a system called "M0" , that had a grammar for interpreted email scripts.
Oh, and don't forget LISTSERV and Majordomo!
Using smarts to guess the information and context of a given message does definitely have ancestors in software that would scan USENET postings for useful stuff. Remember that originally USENET was more like email and predated the "news:" protocol.
You're right! After years of writing documents, I try to avoid stuff like that, along with "should" and "must," as if it's implying something official. I nee^H^H^H will try to be more careful.
Of course. That's why I said "keep maintaining 1.x." ^^ Yes, I know that there is a huge installed base of 1.x. Keep 1.x runtimes in maintenance mode in perpetuity to support them, but allow people to benefit from years of lessons learned about what is needed in the runtime.
It's good to see that there is at least one project aimed at cleaning up old legacy code. The thing needed most by Java, IMHO, is not more features, but a thorough cleanup of the runtime classlib. The packages and classes need to be rearranged logically, renamed, made to have consistent API's and naming patterns. Redundancies need to be removed (like 3 different RPC schemes and APIs), and deprecations finally need to be pruned. Collections- and non-collections-containers need to be merged, and AWT and Swing need to be reconciled. There needs to be a declarative GUI design grammar. Maybe JavaFX's grammar could be borrowed for that. And the long-promised merging of Swing and Collections needs to happen, too. (Like a popup list could be accessed as a java.util.List)
I have thought for years that there needs to be a "JDK 2.0" series started which would be a clean break from the 1.x series. Keep maintaining the 1.x series, but make a fresh start.
First the spec development process, then the time-to-market, and now the market shakeup are all making certain that both standards will be obsolete by the time that one of them has one their little war.
Neither one is anywhere near cutting edge any more, as technology marches on.
> I would think delivery vehicles directly support the community.
Exactly what I meant. The vehicles necessary to run the place, not the extraneous traffic that people bring in from other places. I was in agreement with his viewpoint, but I guess he didn't notice.